Comment On Crash Test _dummy

This is a sad story ...

Well, of course it crashed; you can't expect Enterprise Level Software to be able to take the first four natural numbers for granted.  Christ, have you people never heard of modularity?!

 

This s bad. Oh so very bad

Well you know its always handy to be able to count to 4...

as an added bonus SQL does not guarantee row order.  I wonder how much code is in there to deal with

> SELECT * FROM _dummy

Results: 4,1,2,3

Just Another WTF:

Well you know its always handy to be able to count to 4...

as an added bonus SQL does not guarantee row order.  I wonder how much code is in there to deal with

> SELECT * FROM _dummy

Results: 4,1,2,3

You are assuming it's actual integer data. Could be strings: '1', '2', '3', '4', '-1', 'File Not Found', ...

Everyone knows that you have to test those pooled db connections and throw them back if they are no good before actually trying to do something meaningful with them.

 

Sheesh. 

He searched the code and didn't find all the things that obviously depended upon this table?

Granted, the table seems useless, and probably is (maybe a leftover from something that once contained something useful for debugging?), but finding all the references should have been fairly easy. The artcle mentioned he found stored procs that referenced the table. Did he search the actual code?

 

So what was it actually using "_dummy" for?  We need more details here.

Anonymous:

He searched the code and didn't find all the things that obviously depended upon this table?

Granted, the table seems useless, and probably is (maybe a leftover from something that once contained something useful for debugging?), but finding all the references should have been fairly easy. The artcle mentioned he found stored procs that referenced the table. Did he search the actual code?

 

I believe that he did find all the occurences.

The problem could have been a timing issue.  

Just Another WTF:

Well you know its always handy to be able to count to 4...

as an added bonus SQL does not guarantee row order.  I wonder how much code is in there to deal with

> SELECT * FROM _dummy

Results: 4,1,2,3

True, although in some implementations, you'll get the same result every time.  For example mysql's innodb storage engine actually stores table data in primary key order. 

nice!

the behemoth sounds like an under-engineered management masterpiece that breaks down once you open a file and work on it.  BTW it's your responsibility now for the behemoth breaking you worked on it last.  Even if it is nothing more than "hey comment that module" and re-compile it.

<sadism: managers who don't know anything managing know-it-all developers/>

I thought maybe the Tantalus reference was one about a book I had many many years ago, called, if I recall, the Tasks of Tantalus, which was a kids puzzle book, sort of like The Egyptian Jukebox, sorta.  Anyway, I can't really find a reference online anymore about it, so I might have imagined it.

Every day thedailywtf has been getting closer to describing what I work on.  Today you hit it right smack bang in the middle.

What you see here is an example of 'The [insert project name] Butterfly'.  The Butterfly is much like the butterfly effect, except that instead of the flapping of the butterfly's wings causing a long chain of events which eventually lead to a catastrophic weather event, it is the butterfly itself whose 100ft wide leathery wings, razor sharp talons, and flesh-eating acidic excrement cause unexpected carnage throughout your codebase as it is exorcised from the code.

 An example from my project was a table called something like "usa_company" which contained a single column called "company" (varchar(20) of course) and a single row saying something like "ACME Suchandsuch".  One of the team piped up "we can drop this right" and i was so sure that there was no possible use for the table that I told them to delete it without even checking the code.

 
We got a tech support call withing 30 seconds.
 

Rick:

Anonymous:

He searched the code and didn't find all the things that obviously depended upon this table?

Granted, the table seems useless, and probably is (maybe a leftover from something that once contained something useful for debugging?), but finding all the references should have been fairly easy. The artcle mentioned he found stored procs that referenced the table. Did he search the actual code?

I believe that he did find all the occurences.

The problem could have been a timing issue.  

So you're guessing that "select * from _dummy" is an enterprisey equivalent to "sleep(30)" - priceless!

** What Erik said :)

 

I recently ran into a problem like this with an in-house application. A seemingly empty and unused table, would make the application crash at startup if removed.

When I traced the exception, I found a line of code in the startup procedure that actually checked if that table was present, and threw an unhandled exception if it wasn't.

And if course, right above that line, there was a comment. "// FIXME. Remove this before launch".
Good thing i remembered to search the code for those "FIXME's" the day after the code went into production.

And now the table can never be removed, because you know someone is still running that version of the software.

I love my job.
 

CAPTCHA: jiggles... 

I was just looking through some code in my current project, and found a similar table: one integer column, 1 row. Of course, our table is named: NextTxnNum.

I wonder if this WTF iss possibly an example of a similar table of counters with hard-wired indices (perhaps (poorly) presuming order of return values)? I supposed it depend upon how much Alex anonymized...

It looks like Wil Wheaton being strangled by a pizzaria tablecloth.

Anonymous:

Rick:

Anonymous:

He searched the code and didn't find all the things that obviously depended upon this table?

Granted, the table seems useless, and probably is (maybe a leftover from something that once contained something useful for debugging?), but finding all the references should have been fairly easy. The artcle mentioned he found stored procs that referenced the table. Did he search the actual code?

I believe that he did find all the occurences.

The problem could have been a timing issue.  

So you're guessing that "select * from _dummy" is an enterprisey equivalent to "sleep(30)" - priceless!

No.  Bue people often write in a "experimental mode" where fast trial and error changes on the code search the "magic" value that not-crash the program. This own we can see code like this one:

 for (t=3;t< max -pad +22;t++){ //22 work, 21 crash and 23 corrupt all data. Please use 22.
    if (! t %7) buff[t] |= 1;
}
 

 

Anonymous:

What you see here is an example of 'The [insert project name] Butterfly'.  The Butterfly is much like the butterfly effect, except that instead of the flapping of the butterfly's wings causing a long chain of events which eventually lead to a catastrophic weather event, it is the butterfly itself whose 100ft wide leathery wings, razor sharp talons, and flesh-eating acidic excrement cause unexpected carnage throughout your codebase as it is exorcised from the code.

 That made me laugh.

 I think I know why they had a dummy table. It could be one of these instances where a stored proc. does a few operations before returning a final resultset, and they added a _dummy table to square up the result sets with the app. Of course, there's also set nocount on which would have fixed that.

That's a WTF! Dropping production tables without testing changes on a test database in a test environment!\

 Captcha: Clueless
 

Rick:

Anonymous:

He searched the code and didn't find all the things that obviously depended upon this table?

Granted, the table seems useless, and probably is (maybe a leftover from something that once contained something useful for debugging?), but finding all the references should have been fairly easy. The artcle mentioned he found stored procs that referenced the table. Did he search the actual code?

 

I believe that he did find all the occurences.

The problem could have been a timing issue.  

oh for farks sake

It's a delay? Calls to that table are delays?

What does this code do, summon Cthulhu? 

 

One piece of code I wrote (years ago, as a student) required me to have a table just as a dummy. It was for MS Access, and the place I worked for wanted some SQL that wasn't part of the built-in code. They wanted to be able to sort by types of problems, then have those problems automatically generate a report.

Anyway, the help I got from some online groups was that I had to have a dummy table to run the query and report against. It did work, even though it was total nonsense.

I called the table "Never Ever Delete This Table" and just in case, checked
for it on startup and created a new table if it ever got deleted.

Probly didn't search for:

 SELECT * from /055/144/165/155/0x6D/131

Ya gotta watch out for those things. 

Anonymous:

I thought maybe the Tantalus reference was one about a book I had many many years ago, called, if I recall, the Tasks of Tantalus, which was a kids puzzle book, sort of like The Egyptian Jukebox, sorta.  Anyway, I can't really find a reference online anymore about it, so I might have imagined it.

Wikipedia's got you covered: 

Tantalus' punishment, now proverbial for temptation without
satisfaction, was to stand in a pool of water beneath a fruit tree with
low branches. Whenever he reached for the fruit, the branches raised
his intended meal from his grasp. Whenever he bent down to get a drink,
the water receded before he could get any. Over his head towers a
threatening stone, like that of Sisyphus.

Of course, it may also refer to the Tantalus Field from the Star Trek episode "Mirror, Mirror." It was a machine that ended careers, also. Of course, it ended your career by ending your life, but the principle is the same.

Anonymous:

Every day thedailywtf has been getting closer to describing what I work on.  Today you hit it right smack bang in the middle.

What you see here is an example of 'The [insert project name] Butterfly'.  The Butterfly is much like the butterfly effect, except that instead of the flapping of the butterfly's wings causing a long chain of events which eventually lead to a catastrophic weather event, it is the butterfly itself whose 100ft wide leathery wings, razor sharp talons, and flesh-eating acidic excrement cause unexpected carnage throughout your codebase as it is exorcised from the code.

 An example from my project was a table called something like "usa_company" which contained a single column called "company" (varchar(20) of course) and a single row saying something like "ACME Suchandsuch".  One of the team piped up "we can drop this right" and i was so sure that there was no possible use for the table that I told them to delete it without even checking the code.

We got a tech support call withing 30 seconds.
 

 

Wait...to get a tech support call in 30 seconds....you must have been dropping tables on a PRODUCTION database. Ummm, I'm sorry but you deserved that.

I found the part about getting first hired by a smaller firm interesting. Is that usual? Around where I went to school, all the big companies were snatching people out of college so they could mold them into the type of developer they wanted.

 

He dropped the table from the developmestruction database, of course!

vecctor:

I found the part about getting first hired by a smaller firm interesting. Is that usual? Around where I went to school, all the big companies were snatching people out of college so they could mold them into the type of developer they wanted.

 It's that way for me, although I'm in Michigan, home to the greatest unemployment in the states.

Several years ago, I had such a table - called DUMMY - with one column - DUMM - that would contain one or more lines with the value 'X'. Droping the table would have crashed the whole application. (So if this application was still in production, and someone else had to maintain it, I would guess it's my app, a bit anonymized...)

The reason for that was the behaviour in Oracle's SQL*FORMS version 3. In Forms, you could call stored procedures, or write DML statements in the triggers (event handlers), but the only way to make it do a COMMIT was to change a database-bound-field. Unfortunately, I didn't want to use database-bound-fields - for several reasons - so every form had a datablock bound to DUMMY, with a field bound to DUMM. There was a procedure "dummy_commit" like this:

go_block('DUMMY'); 

exectute_query; 

:DUMMY.DUMM := 'X';

commit;
 

Anonymous:

vecctor:

I found the part about getting first hired by a smaller firm interesting. Is that usual? Around where I went to school, all the big companies were snatching people out of college so they could mold them into the type of developer they wanted.

 It's that way for me, although I'm in Michigan, home to the greatest unemployment in the states.

Of course this is also leads to most developers coming straight out of college making 24k a year.  Which is an improvement from the 21k a year i was making washing dishes in a nursing home. 

Anonymous:

I thought maybe the Tantalus reference was one about a book I had many many years ago, called, if I recall, the Tasks of Tantalus, which was a kids puzzle book, sort of like The Egyptian Jukebox, sorta.  Anyway, I can't really find a reference online anymore about it, so I might have imagined it.

I had that book too - it was the Tasks of Tantalon.

 

It's like what the Cancer-Man in the X-Files said:

"When you see a man's hopes and dreams crushed...  well... that's a beautiful thing."

 

Well, Oracle has the Dual table:

Select * from Dual:

| DUMMY |

----------------

|  X  |

 
This is because you can't just do SELECT 'Some String stuff'; it has to be from a table. Thus they look like: SELECT 1, 2 FROM Dual.

Imagine what would happen if someone added a row, or deleted the single row in this table...

 

Anonymous:

Rick:

Anonymous:

He searched the code and didn't find all the things that obviously depended upon this table?

Granted, the table seems useless, and probably is (maybe a leftover from something that once contained something useful for debugging?), but finding all the references should have been fairly easy. The artcle mentioned he found stored procs that referenced the table. Did he search the actual code?

I believe that he did find all the occurences.

The problem could have been a timing issue.  

So you're guessing that "select * from _dummy" is an enterprisey equivalent to "sleep(30)" - priceless!

 And when they move to faster hardware, all they have to do is add more rows to the table. Scalable!!!

 

Anonymous:

I was just looking through some code in my current project, and found a similar table: one integer column, 1 row. Of course, our table is named: NextTxnNum.

 I have a table like that, and the purpose is to simulate sequences on MS SQL Server, which doesn't support them.
(I need to get a consitently increasing number, with no gaps, so rollback to this should rollback the new value).
 

merreborn:

Just Another WTF:

Well you know its always handy to be able to count to 4...

as an added bonus SQL does not guarantee row order.  I wonder how much code is in there to deal with

> SELECT * FROM _dummy

Results: 4,1,2,3

True, although in some implementations, you'll get the same result every time.  For example mysql's innodb storage engine actually stores table data in primary key order. 

 Are you sure about that ?

Wouldn't it make inserts O(n) instead of O(1) ?

 

Anonymous:

Anonymous:

We got a tech support call withing 30 seconds.
 

 

Wait...to get a tech support call in 30 seconds....you must have been dropping tables on a PRODUCTION database. Ummm, I'm sorry but you deserved that.

Hell yeah.  On my project, it's so difficult to tell the difference between the the system 'working' and being broken that we do stuff like this from time to time just to see what will happen.

Anonymous:

Well, Oracle has the Dual table:

Select * from Dual:

| DUMMY |

----------------

|  X  |

 

This is because you can't just do SELECT 'Some String stuff'; it has to be from a table. Thus they look like: SELECT 1, 2 FROM Dual.

Imagine what would happen if someone added a row, or deleted the single row in this table...



 

I've heard it is harder to modify DUAL these days, but in Oracle 8 I've seen it done. Needless to say it has far-reaching consequences.

IBM DB2 solved the problem by creating a ONEROW view, using the cool DB2 "VALUES" query construct. Since its a non-updatable view, you don't have to worry about adding or deleting rows. Although, I suppose you could modify the view and still cause problems.

Anonymous:

Everyone knows that you have to test those pooled db connections and throw them back if they are no good before actually trying to do something meaningful with them.

 

Sheesh. 

I had the same thought as "Harry" - it was probably using that table to test database connections.

 

Too bad no one told the programmer about "SELECT 1"
 

That's nice and all... but uh.... instead of creating an internal-IT project to "clean up" the unused parts of The Behemoth, it would have been smarter to implement a regression test so that any code changes they make wouldn't break anything. If you have a bug and can reproduce it, you can throw it into a test. After every code change before release you ensure that the regression test runs and has the same output as the last build. What the hell. That's the WTF. Trying to clean up a known buggy application that doesn't have proper testing is like trying to play jenga forever. WTF.

Now that you mention it, I think that may have been what it was used for.  I used to work on this behemoth and was there to see Rob's frustration first hand.  I'm sure he found all occurrences of "_dummy" because he probably just ran "grep -R '_dummy' *" on the main level of the app (err.. i mean behemoth).  I remember taking a stab at it as well and gave up after an hour or so.  It never occurred to me that someone would use an SQL query to 'simulate' a sleep command.  My brain just doesn't think that way (fortunately).

Anonymous:

Anonymous:

Every day thedailywtf has been getting closer to describing what I work on.  Today you hit it right smack bang in the middle.

What you see here is an example of 'The [insert project name] Butterfly'.  The Butterfly is much like the butterfly effect, except that instead of the flapping of the butterfly's wings causing a long chain of events which eventually lead to a catastrophic weather event, it is the butterfly itself whose 100ft wide leathery wings, razor sharp talons, and flesh-eating acidic excrement cause unexpected carnage throughout your codebase as it is exorcised from the code.

 An example from my project was a table called something like "usa_company" which contained a single column called "company" (varchar(20) of course) and a single row saying something like "ACME Suchandsuch".  One of the team piped up "we can drop this right" and i was so sure that there was no possible use for the table that I told them to delete it without even checking the code.

We got a tech support call withing 30 seconds.

Wait...to get a tech support call in 30 seconds....you must have been dropping tables on a PRODUCTION database. Ummm, I'm sorry but you deserved that.

Our users aren't smart or coordinated enough to reach for the phone, let alone look up a number, let alone dial it, let alone complain over it all in 30 seconds.

Ghost Ware Wizard:

BTW it's your responsibility now for the behemoth breaking you worked on it last.  Even if it is nothing more than "hey comment that module" and re-compile it.

The Real WTF(tm) is re-compiling code after you've just added comments.

Anonymous:

merreborn:

Just Another WTF:

Well you know its always handy to be able to count to 4...

as an added bonus SQL does not guarantee row order.  I wonder how much code is in there to deal with

> SELECT * FROM _dummy

Results: 4,1,2,3

True, although in some implementations, you'll get the same result every time.  For example mysql's innodb storage engine actually stores table data in primary key order. 

 Are you sure about that ?

Wouldn't it make inserts O(n) instead of O(1) ?

 

 

Yes it will. However, for many applications, the added overhead of storing data this way (MS SQL Server calls it a "clustered index", and usually creates one on the primary key if you define the PK in Enterprise Manager) is far, far outweighed by the performance gain in searching for a record matching a particular PK.
 

I too work on Behemoth.  I too had hope and ideas; Behemoth laughed at the twinkle in my eye.  I used to wonder how people could've written this or that.  That was before I realized Behemoth's power.  My code looks more like what Behemoth likes all the time.

Nobody intentionally designes a Behomoth (obviously), but yet the beasts exist.  I have several reasons why I must stay and serve him; perhaps his hooks are getting into my very mind.

Must.. fight.. his.. powers... 

Anonymous:

This is because you can't just do SELECT 'Some String stuff'; it has to be from a table. Thus they look like: SELECT 1, 2 FROM Dual.

Which bring up one of my favorite WTFs:  Oracle dbs have a table, the important feature of which is that it has just ONE row, which they gave a name which means TWO.

 

Anonymous:

merreborn:

Just Another WTF:

Well you know its always handy to be able to count to 4...

as an added bonus SQL does not guarantee row order.  I wonder how much code is in there to deal with

> SELECT * FROM _dummy

Results: 4,1,2,3

True, although in some implementations, you'll get the same result every time.  For example mysql's innodb storage engine actually stores table data in primary key order. 

 Are you sure about that ?

Wouldn't it make inserts O(n) instead of O(1) ?

It would make inserts O(log(n)) or O(n) with a very small constant.

Primary keys need to have indexes (or reasonable facsimile) to implement the unique constraint.  The two popular data structures that are typically used for this purpose are btrees (O(log(n))) and hash tables (O(n) with a very small constant--you divide n by say 16 million and search that number of rows in the hash bucket).

cowboy_k:

Anonymous:

merreborn:

Just Another WTF:

Well you know its always handy to be able to count to 4...

as an added bonus SQL does not guarantee row order.  I wonder how much code is in there to deal with

> SELECT * FROM _dummy

Results: 4,1,2,3

True, although in some implementations, you'll get the same result every time.  For example mysql's innodb storage engine actually stores table data in primary key order. 

 Are you sure about that ?

Wouldn't it make inserts O(n) instead of O(1) ?

 

 

Yes it will. However, for many applications, the added overhead of storing data this way (MS SQL Server calls it a "clustered index", and usually creates one on the primary key if you define the PK in Enterprise Manager) is far, far outweighed by the performance gain in searching for a record matching a particular PK.
 

 
It says "Table Data" in the OP. Not index data.

Binary tree and appending inserts sounds faster but I guess they know more about it than me.

 

 

That tie is BOSS.

themagni:

Rick:

Anonymous:

He searched the code and didn't find all the things that obviously depended upon this table?

Granted, the table seems useless, and probably is (maybe a leftover from something that once contained something useful for debugging?), but finding all the references should have been fairly easy. The artcle mentioned he found stored procs that referenced the table. Did he search the actual code?

 

I believe that he did find all the occurences.

The problem could have been a timing issue.  

oh for farks sake

It's a delay? Calls to that table are delays?

What does this code do, summon Cthulhu? 

 

It might hold a lock on the rows in the table or the table itself.  That might force other updates to be serialized which might (without the select on dummy) execute in random order and cause deadlocks. If there are transactions floating around in isolation level serializable mode, that (and even stranger things) does happen.

 I wonder what happens if you add or remove rows from the table?
 

Saladin:

Ghost Ware Wizard:

BTW it's your responsibility now for the behemoth breaking you worked on it last.  Even if it is nothing more than "hey comment that module" and re-compile it.

The Real WTF(tm) is re-compiling code after you've just added comments.

I think he means to comment out that module, not add comments to it.
 

Long ago last century, I worked for a "computer vendor", one of the companies referred to as the Seven Dwarfs ------

I was assigned maintenance of a program that was littered with statements such as

size = size * 1.0;

Being naive, I asked "WTF" and was told "We Don't Know". The programmer who did that has been gone for many years. We took them out once and the results were disasterous.

 Fortunately I learned my lesson early in my career.  Some questions have no answers and are not even worth answering.