• Prime Mover (unregistered)

    Well that's just appalling. Magic numbers all over the place: 64, 32, 16 -- gaah.

  • Jeff Jefferson (unregistered)

    I look forward to seeing this submitted in a year's time.

    How many bodges are put in just to get around management?

  • Profke (unregistered)

    only one way: let the boss handle the DB committee. Tell him: "ill write the code, you make sure the DBA's update the scheme"

    If , in that case, his fields are not there, atleast it's clear DBA is the isue, and not the coding team

  • (nodebb) in reply to Jeff Jefferson

    It all depends on how many different applications are dependent on the schema. Do they all need to update their persistence layer to incorporate changes made in response to the needs of other applications? Why are they still using multiple applications tightly bound directly to the database?

    But "clever" undocumented hacks like this quickly turn into an existential threat to the very database which DBAs so tightly safeguard. If everyone adopted the same approach as Gus, where he's started by stuffing unnamed flags into a varchar column as an integer, which has the chance of looking either like garbage which some well-intentiond DBA might "clean up", or in the worst case, maybe interpreted as a phone number if the bit-field evolves in exactly the right way.

    Even though this is also a disgusting practice, it would be actually cleaner to put JSON or XML in the same field, as it is at least somewhat self-describing, and has the side benefit of allowing others to "gracefully extend" the hack if so desired.

  • NoLand (unregistered) in reply to caffiend

    it would be actually cleaner to put JSON or XML in the same field

    It may be a bit difficult cramming JSON or XML in a self-describing manner into an existing varchar(10)field, though.

  • dusoft (unregistered) in reply to NoLand

    Still, how is using a separator not better? 1-0-1-xxxxx

  • Hans (unregistered)

    Earlier version: https://thedailywtf.com/articles/just-the-fax-ma-am

  • pif (unregistered)

    But Gus was smart

    No, he was not. He was an idiot!

    Processes are established for a reason. Developers are not trusted for a reason. Gus is the reason.

  • pif (unregistered) in reply to caffiend

    Absolutely, the Real WTF is Gus.

  • Sole Purpose Of Visit (unregistered) in reply to dusoft

    Better still, just make it look like a fax number. Ten digits (making sure (3-5) are "555" for obvious reasons), preface with whatever the local area code is, and Bob's your four-bit binary. Which allows for an additional boolean, so it's future-proof!

    Make it more future-proof by encoding all three bits into the final digit: 0x30 + 4b2 + 2b1 + 1*b0. Up to twelve booleans!

    Last time I did this sort of thing was on an embedded Z80 device, but I guess it works for massive great RDBMSs as well.

  • The Dave G (unregistered) in reply to pif

    Agreed. Gus is an idiot. A lucky idiot. What if some of the fax fields already had data?

  • Naomi (unregistered)

    Guys, it's really easy to say "Gus is an idiot" when it's not your livelihood on the line.

  • Andrew (unregistered)

    Database field reuse is the root of all evil.

  • Pabz (unregistered)

    This sounds like a complete lack of planning on the part of the big boss, who should know the processes that are in place before demanding that something is done "yesterday". I agree with letting the boss deal with the DBAs.

  • 516052 (unregistered) in reply to Naomi

    I concur. The true sad fact of the matter is that neither the DB nor GUS are the idiots here. And neither is the boss. The idiot is the system. For it is the system which forces hacks such as this and they in turn force the DB's to want the system. It's horrifying and yet unavoidable like a plague.

  • (nodebb)

    Eventually we've learned how SQL WTFs come into existence.

  • John Melville (unregistered)

    Put my vote in for the DBA is the idiot.

    When you make the right thing difficult people will inevitably do the wrong thing. Gus broke the database, but the DBA gave him an engraved invitation do so by making the right thing impossible in the time period that Gus' boss wanted the work done.

  • Duston (unregistered) in reply to 516052

    Yet another chapter in "For every action, there's an equal, but opposite reaction."

  • pif (unregistered) in reply to Naomi

    It is very easy indeed to say "Gus is an idiot", because he is! After decades of software development, I'm positively sure that there is no quick & dirty hack: what is called quick & dirty ends invariable being just dirty.

  • Brian (unregistered)

    The correct answer here would be the old "bothering by the book" approach. "Sorry boss, I'd love to help you, and I've done all I can, but now it's out of my hands. If you have concerns about the timeline, you should take it up with the DBAs." In the best case, it'll bring scrutiny on a burdensome process by someone with the power and motivation to do something about it; in the worst case it'll get you fired and you can move on to another job where people's heads aren't stuffed quite so far up their own rears.

  • Ollie Jones (unregistered)

    I worked on a vast and urgent data-migration project once. The target database was Oracle Standard Edition, and the source was, gulp, MarkLogic.

    We had a test Oracle instance where we ran the migration code. Our development process was to run modest tests during each week, then over the weekend run a huge chunk of migration (for testing).

    This required the company's database administrator team to cooperate at a 2pm meeting on Friday; they controlled weekend access to the staging instance.

    I guess they never got the memo about the urgency of the project. I guess the company's management couldn't or wouldn't explain it to them. They didn't want to do this weekend stuff: too much like work. So they changed their working hours to knock off at noon on Friday. So we moved the job-start meeting to 11am. They scheduled other meetings so they couldn't make ours.

    So, when my manager told our development team we had to work weekends because the project was behind, I gave notice. Working weekends was futile without access to the database instances.

    I will never work on Oracle-based data projects again. Too many bad experiences with DBAs in that environment. (Also, too expensive).

  • Sigh (unregistered)

    it's availability is vital

    Oh dear, oh dear.

    the FAX_PHONE_NUMBER field on all of their customer records were blank.

    the ... field ... WAS blank

  • Jason Stringify (unregistered) in reply to NoLand

    It may be a bit difficult cramming JSON or XML in a self-describing manner into an existing varchar(10) field, though.

    In many places it'd be quite hard even to fit a fax number - sorry, fax PHONE number - into a varchar(10).

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered) in reply to Sole Purpose Of Visit

    Ten digits (making sure (3-5) are "555" for obvious reasons), preface with whatever the local area code is, and Bob's your four-bit binary

    Actually, only the 555-01xx range of numbers are reserved for fictitious use; the other 555-yyxx (where yy ≠ 01) numbers are perfectly valid for phone operators to use. The remaining 5 digits (area code + last 2) are still enough to stuff 3 boolean flags into of course, but 5 digits of information could be significantly more restrictive than 7 digits should additional fields need to get stuffed in there in the future.

  • Daniel Orner (github)

    Just because the field is blank doesn't mean no one is displaying it in a view somewhere. Suddenly millions of customers are showing garbage fax numbers in their profile. Yowza.

    Having said that, yes, the right approach would absolutely have been "I literally can't do this by the rules of our own company; if you want them changed, you need to speak with people that can change them". It's not the developer's job.

  • Retired DBA (unregistered) in reply to Andrew

    Correction: Evil (processes like those) are the root of all database field reuse. I've got the scars to prove it.

  • ZZartin (unregistered)

    And the next rule added will be all database update statements have to go through the committee as well.

  • Mike (unregistered)

    Many, many years ago, I worked at a place with similar rules. The developers had to create a new system, and they said, "F*** the DBAs. We'll store everything in strings, and control our own destiny." By the time I got there, this was widely regarded as a mistake. Nothing else could read their data, so they supported 2 other databases that replicated their data, so other systems could read their data. The system was featured here years ago. Unfortunately, I can't easily find the link. At one point, I asked a DBA for a new table. After explaining why, he replied, "you really want to use feature X," which actually made my life easier. So, not all DBAs are bad.

  • ooOOooGa (unregistered)

    Hmm... Adding a new table is pretty trivial risk to the existing data in a database.

    Adding new fields to an existing table is also fairly low risk. The biggest problem I can think of is the time needed for it on a huge, heavily used database. And if that is the case for this database, the DBAs should already have methods for changing the schema with minimal database performance impact.

    So having draconian change request procedures for this is unnecessary. Draconian process for modifying or removing data, sure. But minimal process for adding fields (to avoid unneeded database bloat).

    So my ruling: Company gets a major WTF for allowing the DBAs to avoid work by having a draconian process for change requests. Manager gets a major WTF for mismanaging the schedule and needing a schema change yesterday. Grumpy Gus gets a major WTF for not insisting on getting it in writing that this kludge is being made under duress (and probably for even suggesting it in the first place). Upgrade that to a grand WTF if Grumpy Gus made the change without running it past tech lead or other peers. The actual kludge is a fairly minor WTF. If it is refactored quickly (hah. ha ha ha hah ha.) then it won't kick someone in the teeth too badly later.

  • (nodebb)

    The problem here is that there are a lot of processes and no sound architecture. If they had a set of rules to decide what goes in and what doesn't, they would not need a million committees.

  • D-Coder (unregistered) in reply to Duston

    Yet another chapter in "For every action, there's an equal, but opposite reaction."

    D-Coder's addition to Newton's Law: "...but usually too late to do any good."

  • aalien (unregistered)

    At least the fax number field wasn't bigint.

  • (nodebb) in reply to Ollie Jones

    I will never work on Oracle-based data projects again. Too many bad experiences with DBAs in that environment. (Also, too expensive).

    I can't speak for other Oracle DBAs, but I can say it's not a good look on you to never work with a product because the guys that ran it "once" were assholes. As for the cost.... Well, yes, Oracle is expensive. But if you configure Oracle correctly, it's not in any way possible to lose transactions. This can't be said for all databases, but we don't need to mention names here. Classic case of "You get what you pay for."

    That said, I agree 100% with ooOOooGa's assessment of the WTFs: Company, Manager, Gus, the actual hack. And I will add the DBAs -- because they're obviously not doing their jobs of supporting users in getting their work done.

  • ZZartin (unregistered) in reply to ooOOooGa

    So having draconian change request procedures for this is unnecessary. Draconian process for modifying or removing data, sure. But minimal process for adding fields (to avoid unneeded database bloat).

    It's not a DBA's job to facilitate adding everything a developer wants added to the database. You end up with procedures like this because developers want to add garbage to the database instead of learning proper database design. The DBA's get sick of trying to teach them so they just put a bureaucracy wall in front of it, because a good DBA has better things to do.

  • Mike (unregistered) in reply to ooOOooGa

    The problem with adding fields is that it can break anything using "select ." I recently added a column to a table. Later, I discovered that a view was broken in a weird way. The view included "select a., b.col1...". What the view thought was b.col1 was actually a column with a different type from table a. That was a fun bug to diagnose. Recompiling fixed the problem, but I went ahead and removed the * and enumerated the columns the view returned to be sure.

  • Hasseman (unregistered)

    Alex had an article about the inner platform? Seen a few "solutions" to databases making it flexible to add new fields/properties/attributes (not columns in tables) to an application. Adding new business data items are easy. Query them can be a challenge. Mostly it must be solved with multiple queries and data merged in code to make it useable.

    Depending on business I would sometimes go for the inner platform.

  • jay (unregistered)

    When you have cumbersome and stupid rules, people are eventually going to figure out ways to circumvent the rules.

    It's like political activists who think that if they can just pass a law saying, "you are not allowed to do X", that this means that no one will do X. No, it just means that people who want to do X will find loopholes in the rules, ways to hide what they're doing, etc.

  • richarson (unregistered) in reply to ZZartin

    "The DBA's get sick of trying to teach them so they just put a bureaucracy wall in front of it, because a good DBA has better things to do."

    I fail to see how organizing and attending several meetings in several comitees are "better things to do" than implementing a requested change (or just saying "NO." to it).

  • Premature Optimisation Pills (unregistered)

    There's nothing more permanent than a temporary solution. This wouldn't have gone well further down the line.

    Seems like a clever idea until some process performs an action if the field isn't empty, or until someone realises that the field has obviously invalid values, assumes a bug and wipes them.

  • Meir (unregistered)

    I see the WTF. It should have been:

    HAS_DOCK * 64 + HAS_LOCK * 32 + HAS_GLOCK * 16

    (Glocke = German for “bell”)

  • Barf4Eva (unregistered)

    oh hell no

  • 516052 (unregistered) in reply to richarson

    Me 2. But my current place of work is full of people who seem to only exist to hold meetings. Like they don't actually do anything or contribute in any way. They just hold meetings. You should have seen the panic when corona started and company rules meant they couldn't get together 10 times a day in person to chat so they had to settle for teams calls. Like, you could literally see the light leave their eyes in despair.

    The worst part is they are in charge of everything.

  • (nodebb) in reply to 516052

    As the saying goes: Meetings: The Modern Alternative To Work!

  • (nodebb) in reply to ooOOooGa

    Hmm... Adding a new table is pretty trivial risk to the existing data in a database.

    Adding new fields to an existing table is also fairly low risk.

    Depends on what you count as a risk. If you think of the data not being normalised afterwards as a risk, both of these operations are most definitely risks.

    For example, take the three booleans. If they actually represent information that can already be derived in other ways, they really should not be added. For example, I once came across a database with a column hasCustomers or similar, which could have been derived by counting the customer rows for the supplier and comparing to zero. Of course, some queries used the boolean, some used the count and the boolean could get out of sync because nobody thought to put any constraints or triggers on to keep the flag in sync.

  • (nodebb) in reply to ooOOooGa

    Hmm... Adding a new table is pretty trivial risk to the existing data in a database.

    Adding new fields to an existing table is also fairly low risk.

    Depends on what you count as a risk. If you think of the data not being normalised afterwards as a risk, both of these operations are most definitely risks.

    For example, take the three booleans. If they actually represent information that can already be derived in other ways, they really should not be added. For example, I once came across a database with a column hasCustomers or similar, which could have been derived by counting the customer rows for the supplier and comparing to zero. Of course, some queries used the boolean, some used the count and the boolean could get out of sync because nobody thought to put any constraints or triggers on to keep the flag in sync.

    Addendum 2021-10-28 04:29: I promise I didn't press the submit button twice.

  • Dave (unregistered)

    TRWTF is that no-one's explained the right way to deal with this.

    The OP should have explained to his boss that he'd come up with the code in [hours], but there was no urgent-change procedure, so that boss needed to call urgent meetings for this group, that group, and the other group, and get them to approve the changes. Use exactly the same process, and force emergency meetings to deal with the urgent change.

    Either this will be relatively trivial to implement, or there are obstructive sods the big boss will run into and crush. If big boss isn't sufficiently big, then he needs to kick it up the chain to whoever is big enough and ultimately responsible for whatever requires the urgent change.

  • Guest (unregistered) in reply to Bananafish

    "But if you configure Oracle correctly, it's not in any way possible to lose transactions."

    Unless your transaction has data that considers string null and empty string ("") to be two different things.

    I love the fact that people think Oracle is a useful database. If they didn't I wouldn't make half of what I do :)

Leave a comment on “Committed Database”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article