Comment On DELETE. No, INSERT! No, SELECT!

uh, ok?

Maybe the comment asks for authorization to delete things?

WTF for bad wording.

SQL in XML CDATA.

Fire the programmer. WITH FIRE.

Putting all your SQL in one place isn't the worst idea mankind has ever come up with.

What disturbs me more is thinking about the code that would call something named 'delete' and expect the results of a select to come back.

First!

Well, I would have been, but the query "post_first_comment" turned out to select the existing first comment and delete it.

I smell some copy-and-paste coding....

You misspelled "Brillant".

anon:

First!

Well, I would have been, but the query "post_first_comment" turned out to select the existing first comment and delete it.

Now if only we could find the query to remove all the noise from the comments...

I would call it obvious security through obscurity, but it is impossible to use the words "obvious" and "obscurity" in the same sentence. (Hence the immeasurable value of security through obscurity.)

select_users....
nope
insert_comment.....
nope
select_date
also not...
I give up I'll have to look this one up in the appropriate XML file

A heck of a lot safer than having a file claim it is going to run a select query only to insert or delete something....

trwtf is that the article was posted without a long meaningless backstory? cheers!

char decrement( int &a )

{

    // Increment an integer

    a = ( a < 0 ? --a : a++ );

    return '*';

}

wow:

trwtf is that the article was posted without a long meaningless backstory? cheers!

On a dark, Tuesday morning, Jan Fabry entered his cubicle at Notech Inc. After all the problems of the morning, he hoped for a calm day. Then, at 10:05, an innocent ticket arrived in his mailbox. Quickly, Jan dived into the source code control system...

FTFY.

Wow, SQL queries in an XML file, that's definitely a new one.

I wonder if they also abstracted the data access to the XML file itself? Surely they wouldn't want to hard-code all the xpaths.

I hope to god that eventually that XML data is stored in a database... Simply because more people's heads need to explode out of frustration.

Aaron:

Wow, SQL queries in an XML file, that's definitely a new one.

I wonder if they also abstracted the data access to the XML file itself? Surely they wouldn't want to hard-code all the xpaths.

Actually, we do those things here at my job, among others :'(

But here, things are even worse: In one application, we store user-entered answers into the database... As xml-clobs. Which, apparently, only a few people mind.

That reminds me... Does anybody know whether one can get used to this kind of pain?

DOA:

Now if only we could find the query to remove all the noise from the comments...

That would be:
DELETE FROM Comments

You said it all in the linked article about "soft coding". Perfect example.

[Post attempt #3]

AlpineR:

char decrement( int &a )

{

    // Increment an integer

    a = ( a < 0 ? --a : a++ );

    return '*';

}

Oh man. That is beautiful :)

The only WTF here is the copy and pasting and that the comments were not kept up to date.

Depending on the application, storing the SQL in an XML file may be a very wise idea.

For instance, different customers have different ideas of what columns they want to see in the "select record" preview table.

If you put the SQL in a config file, you can change it per customer and everyone is happy.

Shannon:

AlpineR:

char decrement( int &a )

{

    // Increment an integer

    a = ( a < 0 ? --a : a++ );

    return '*';

}

Oh man. That is beautiful :)

It is, I love it - maybe I should get it on a t-shirt or something.
Made my day.

PRMan:

The only WTF here is the copy and pasting and that the comments were not kept up to date.

Depending on the application, storing the SQL in an XML file may be a very wise idea.

For instance, different customers have different ideas of what columns they want to see in the "select record" preview table.

If you put the SQL in a config file, you can change it per customer and everyone is happy.

Dude. WTF?
That is a horrible idea.

TGV:

wow:

trwtf is that the article was posted without a long meaningless backstory? cheers!

On a dark, Tuesday morning, Jan Fabry entered his cubicle at Notech Inc. After all the problems of the morning, he hoped for a calm day. Then, at 10:05, an innocent ticket arrived in his mailbox. Quickly, Jan dived into the source code control system...

FTFY.

No no no, it goes like this...

On a dark, Tuesday morning, Jan Fabry entered his cubicle at Notech Inc. After all the problems of the morning, Jack hoped for a calm day. Then, at 10:05, an innocent ticket. Quickly, John dived into the source code control system...

mel:

Shannon:

AlpineR:

char decrement( int &a )

{

    // Increment an integer

    a = ( a < 0 ? --a : a++ );

    return '*';

}

Oh man. That is beautiful :)

It is, I love it - maybe I should get it on a t-shirt or something.
Made my day.

Mel Kaye?

elamberton:

DOA:

Now if only we could find the query to remove all the noise from the comments...

That would be:
DELETE FROM Comments

And then, after purging the Comments table, let's create a PL/SQL trigger, which would disallow inserting a new comment, when its commentID would be lowest in thread.

A little strict, perhaps, but this way we make sure that there will be no irritating "First!!!" etc.

Captcha "genitus". Ahem.

I don't think it's necessarily a bad idea to store the SQL in an XML file. I think if done right it could help readability and the like. Though there are these things called stored procedures that sort of separate the data access from the application code already. Albeit, they're generally a little bit more slow and difficult to maintain, which can be a double-edged sword.

TRWTF is having a name, comment, and action conflict; the same could happen with inline code though.

PRMan:

If you put the SQL in a config file, you can change it per customer and everyone is happy.

Everyone except the poor sod who gets a support ticket in 6 months' time.

SQL != config!

Essentially this is stored procedures for people who have no clue how to use stored procedures.

TRWTF is that there is no WTF. This looks like a config to perform a check to see if a given user has authorization to delete something, not perform the delete action itself.

And while storing SQL in an XML file seems at first blush to be WTFworthy, it could actually work in some circumstances to decouple the details of the database from the application connecting to it. Maybe the app has to work on a number of different systems, and tailoring the XML file to provide the specific SQL for each type of system makes more sense.

So really, no WTF in this. WTF?

You could have the Web Front-End rewrite the XML file based on customer input! Then you wouldn't have to customize the SQL for each site manually.

I can speak for the veracity of this WTF as I have seen the same code with slight differences at two separate fortune companies. I would say which ones but you would probably drop your health insurance and sell your mutual funds.

After some research I discovered the work was the result of one single "architect" who is still bouncing around starting project frameworks for big companies.

Anonymous Organ Donor:

I hope to god that eventually that XML data is stored in a database... Simply because more people's heads need to explode out of frustration.

Too late. A third-party app we integrate with does exactly that. Not in any fancy sense, they literally dump reams of XML - as CLOBs - into a MySQL instance. After much pressure from us, they've added some extra columns for data we commonly query against, but it's still a dog.

blindman:

PRMan:

Depending on the application, storing the SQL in an XML file may be a very wise idea.

Dude. WTF?
That is a horrible idea.

Umm, its what the spring framework is based on. And tis rather popular.

some guy:

TGV:

wow:

trwtf is that the article was posted without a long meaningless backstory? cheers!

On a dark, Tuesday morning, Jan Fabry entered his cubicle at Notech Inc. After all the problems of the morning, he hoped for a calm day. Then, at 10:05, an innocent ticket arrived in his mailbox. Quickly, Jan dived into the source code control system...

FTFY.

No no no, it goes like this...

On a dark, Tuesday morning, Jan Fabry entered his cubicle at Notech Inc. After all the problems of the morning, Jack hoped for a calm day. Then, at 10:05, an innocent ticket. Quickly, John dived into the source code control system...

TRWTF is the way you guys have him turning up in the morning, then hoping for a calm day after the morning, which appears to have passed instantaneously by, then suddenly winding the clock back to what most people would consider pretty much mid-morning.

And no, don't pretend you meant "... suddenly night fell and he was still there at 10:05pm". You're not fooling anybody!

SB:

blindman:

PRMan:

Depending on the application, storing the SQL in an XML file may be a very wise idea.

Dude. WTF?
That is a horrible idea.

Umm, its what the spring framework is based on. And tis rather popular.

Since when does popular = good idea?

Jay Jay:

Since when does popular = good idea?

Since Democracy.

This looks like iBatis. It is a good framework. But, like any framework, it isn't the framework that is the problem, it's how it's being used. And like any code, comments get stale.

This is quite funny.

C.K.:

Putting all your SQL in one place isn't the worst idea mankind has ever come up with.

Except at 3am you are peering at config of config of config (of config of... you get the picture).

The customisation crowd obviously missed the lecture on side effects.

CaptainSmartass:

TRWTF is that there is no WTF. This looks like a config to perform a check to see if a given user has authorization to delete something, not perform the delete action itself.

And while storing SQL in an XML file seems at first blush to be WTFworthy, it could actually work in some circumstances to decouple the details of the database from the application connecting to it. Maybe the app has to work on a number of different systems, and tailoring the XML file to provide the specific SQL for each type of system makes more sense.

So really, no WTF in this. WTF?

Good troll. Here's some chicken for you.

M-egg:

Aaron:

Wow, SQL queries in an XML file, that's definitely a new one.

I wonder if they also abstracted the data access to the XML file itself? Surely they wouldn't want to hard-code all the xpaths.

Actually, we do those things here at my job, among others :'(

But here, things are even worse: In one application, we store user-entered answers into the database... As xml-clobs. Which, apparently, only a few people mind.

That reminds me... Does anybody know whether one can get used to this kind of pain?

Do we work in the same office? I'm one of those people that doesn't mind. See we could have created a large database structure for each different kind of user interaction, all of which get a foreign key to the main table. This has its own problems, as the DB gets "committeed", and we have to wait for the DBA team to create the structure and update any change we could possibly need. Or, we:

Create an object to store the user created data
Serialize it and store it in the CLOB column of the Table
Deserialize it when we need it

The latter is extensible without DBA interaction, which is always a plus. If we create a new way for the user to create answers (imagine a system with several sets inputs that all need to be saved. A new question comes about that has different inputs), we just create a new object and store it in the same CLOB. These inputs never need to be joined or queried on their own, so there's no point in adding complexity.

Just because it's the "Wrong" way doesn't make it a bad solution.


Also we store SQL in the .NET Resources File. This isn't for abstraction. It's to keep the code readable.

campkev:

CaptainSmartass:

TRWTF is that there is no WTF. This looks like a config to perform a check to see if a given user has authorization to delete something, not perform the delete action itself.

And while storing SQL in an XML file seems at first blush to be WTFworthy, it could actually work in some circumstances to decouple the details of the database from the application connecting to it. Maybe the app has to work on a number of different systems, and tailoring the XML file to provide the specific SQL for each type of system makes more sense.

So really, no WTF in this. WTF?

Good troll. Here's some chicken for you.

Don't be foolish. Trolls don't eat chicken.

I think it's a really good idea to decouple the details of the database from the application connecting to it. Shit, even binding column names to variable names is way too restrictive.

I also see no problem with wrapping SQL in an XML file. Let's be honest about this. SQL is a beloved, invariant standard. Why, the standards committee just said so, in 2008. It's not like you'd need any other semantic information.

And maybe the app does have to work on a number of systems. Did you think of that? Did you? I doubt it. Otherwise you'd realise that wrapping an inadequate and incomprehensible piece of vanilla SQL inside a pointless piece of XML is the way to go.

You appear to have no understanding of the miracles wrought by modern technological advances. I pity you.

Captcha: Enterprisey (Shome mishtake, shurely? Ed.)

Anonymous:

SQL in XML CDATA.

Fire the programmer. WITH FIRE.

Off-topic, but I had to comment. I used to think that's what getting fired meant when I was little.

PRMan:

If you put the SQL in a config file, you can change it per customer and everyone is happy.

I see you are a man familiar with sticking things where they don't belong.

truncate comments;

FTFY!

DOA:

anon:

First!

Well, I would have been, but the query "post_first_comment" turned out to select the existing first comment and delete it.

Now if only we could find the query to remove all the noise from the comments...

Like that one?

TRWTF is ANSI-SQL not providing a statement to insert or update rows (like MySQL REPLACE).

So delete_authorization then insert new local authorization is a perfectly valid approach to get the work done.

And as the requirement is to insert / update the local authorisation (as stored in tables S071_AUTHORIZATION, S071_AUTHORIZATION_LOCALE and S071_LOCALE) into table SH17_LOCALE_AUTHORIZATION, why not perform the delete and insert inside a SELECT-TRIGGER on table S071_AUTHORIZATION?

This has the additional advantage that with one statement you not only can update the data, but also retrieve the results!

I must confess i haven't used this technique myself so far, but would like to be able to do.

No problem with the comment WTF, ok. Storing queries in a place where it can be edited later without a downtime of the application might be a good idea, though. Happens a lot here, for report customization. Hardly the application itself changes, but we do get some one-time-ever reports that need only SQL tailoring. Bring the application down to do it? No. Just modify the query appropriately (or even add a new one), and let the application call it.

We use JPA/Hibernate, and we don't like mapping stored procedures to result objects (specially for those one time reports).

I can understand the hate for XML... but removing hard coded SQL from main application code is far from being a bad practice.

xtremezone:

I don't think it's necessarily a bad idea to store the SQL in an XML file. I think if done right it could help readability and the like. Though there are these things called stored procedures that sort of separate the data access from the application code already. Albeit, they're generally a little bit more slow and difficult to maintain, which can be a double-edged sword.

TRWTF is having a name, comment, and action conflict; the same could happen with inline code though.

Why the F would you use XML? You've got a perfectly good database to store those dynamic queries in!

wow:

trwtf is that the article was posted without a long meaningless backstory? cheers!

qft!