Comment On Piecemeal SQL

You agree with yourself? You agree with what you assume other people are going to think? What's going on now?

CommentSystem.getSystem().inform("frist");


/home/Comments/Piecemeal-SQL:1: 'frist' comment not 'frist'.
CommentSystem.getSystem().inform("frist");
^
1 error

Use of constants, at least in an autocompleting IDE, does guard you against typos though...

Didn't we already have a few articles about this specific kind of Soft Coding?

Hmmm... it looks more brillant than brilliant, and I shoud make the obligatory reference to Bobby Tables as although the author thought about the possibility of SQL changing keywords, they didn't consider injection

Besides using string manipulation to build SQL queries, which is a bit last decade, I see no problem with the code.

Where's the WTF? Building query strings (specially managing the spaces between keywords) can be a bit tricky and error prone, so if someone decided to use shortcuts to do it (and again specially if they can be used in multiple places) whats the problem?

Aren't there enough real WTF out there?

Looks like he tried to reinvent LINQ.

Or given that LINQ is fairly new compared to some of the WTFs here, this may be LINQ's great granddaddy.

Has the number of submissions to this site become so low that this is one of the better choices? I sense that Alex is trying to juggle too many projects.

Anyway... In addition to the excessive flexibility of this code, I assume that "mstr" is short for "master". Would typing one extra character really be that much more work so that you don't have the "mental overhead" of having to deal with abbreviations?

Well, at least they don't need to worry about whether or not they included the spaces around " from ", etc.
Of course, for extra flexibility, they should load the strings from an XML file.

One?

Quastiophor:

Loading the strings from XML would be ideal, but perhaps this was on an embedded platform where there was no file system.

That's easy to solve. Read the XML out of a database...

U can always burn the XML into ROM, if the ROM is flashable you can change it if the end of days comes.

Ryan:

Has the number of submissions to this site become so low that this is one of the better choices? I sense that Alex is trying to juggle too many projects.

Anyway... In addition to the excessive flexibility of this code, I assume that "mstr" is short for "master". Would typing one extra character really be that much more work so that you don't have the "mental overhead" of having to deal with abbreviations?

Nah, it looks more like hungarian notation, with "m" denoting a member and "str" the string type. I won't join this particular battle, but as far as I know, Microsoft themselves advise against such notation nowadays.

Seeing as the actual querybuilding routine is written now, this is a valid code beautification approach to my eyes.

Ryan:

In addition to the excessive flexibility of this code, I assume that "mstr" is short for "master".

It's not a abbreviation; it's the pronunciation of an an acronym. "mister" as in "to mist". Or mst, in the case of this website (as opposed to say, a theater with robots).

Now repeat to yourself, it's just a website, you should really just relax.

UserSystem.getUser("x").inform("troll");
CommentSystem.getSystem().inform("failed");

Captcha: secundum - and accurate description of 2nd poster (even computer knows it).

The sql statements are now checked compile time for spelling errors, instead of runtime. I think this is quite clever.

Anonymous Coward:

U can always burn the XML into ROM, if the ROM is flashable you can change it if the end of days comes.

Even better, it might get flashed automatically, if it's a compatible disaster.

Ryan:

Has the number of submissions to this site become so low that this is one of the better choices? I sense that Alex is trying to juggle too many projects.

Anyway... In addition to the excessive flexibility of this code, I assume that "mstr" is short for "master". Would typing one extra character really be that much more work so that you don't have the "mental overhead" of having to deal with abbreviations?

Yes, especially as the extra typing load is that version of ONE that is equal to TWO. (mAstEr)

luctus: no luc posting this tus.

peterchen:

Anonymous Coward:

U can always burn the XML into ROM, if the ROM is flashable you can change it if the end of days comes.

Even better, it might get flashed automatically, if it's a compatible disaster.

I'm thinking that instead of strings, they should be objects. Their .toString method will open a websocket.

That web socket's other end is an underground bunker, where a series of ultra-redundant web-cameras have been set up.

Each web camera (well, array of cameras, to be sure) points to a stone tablet.

On those stone tablets are etched the sacred SQL words.

Each camera will snap a shot of the tablet and send it back over the websocket. It will then be OCR'd, and turned into a string.

Only then can you be sure that SQL survives The Coming Apocalypses.

(Note: Going against all established standards, wooden tables will not be used in the process. They simply do not have the longevity needed to withstand the epochs ahead. Perhaps if they were some form of petrified and rpeserved wood, we will reconsider....)

A strange new world rises from the old: a world of savagery, super science, and new SQL syntax.

This is obviously LINQ-to-bullshit.

Classic soft-coding example, nothing particularly special but sufficiently cringe-worthy I suppose. TRWTF is everyone going on about bloody embedded file systems. Childhood aside, since when did endless repetition = humour?

halcyon1234:

(Note: Going against all established standards, wooden tables will not be used in the process. They simply do not have the longevity needed to withstand the epochs ahead. Perhaps if they were some form of petrified and rpeserved wood, we will reconsider....)

Still too risky. I'd suggest they be etched into corrosion resistant gold plaques as a back up.

That is why stored procedures was invented :D

Well. At least they won't have to worry about adding spaces in the right places, and they won't be able to type "ISNERT" anywhere.

Worst WTF, ever.

A not-so-elegant solution to the irksome string-concatenation nightmares that we've been dealt on occation I rate

Anon:

Still too risky. I'd suggest they be etched into corrosion resistant gold plaques as a back up.

I'm thinking something like this:

Being a DBA, I'd consider this ok for a small Access or other desktop database, but NOT using bind variables requiring the database server to hard parse every statement sent, this is a receipe for a disaster, placing unneccesary load on the server. But oh well, developers ARE lazy, and this is the proof.

millimeep:

Hmmm... it looks more brillant than brilliant, and I shoud make the obligatory reference to Bobby Tables as although the author thought about the possibility of SQL changing keywords, they didn't consider injection

Well actually, we don't get to see how the different bits are built up... perhaps they are properly scrubbed before being assembled into the query string.


PS., I am still looking for the bit of code here that makes me think, "OMGWTF!???", 'cuz I don't see it... Perhaps this is some big buildup towards some sort of April Fool's joke?

There is nothing wrong with this code. It's not super elegant, but it's sufficient for the task. The softcoding may have been an attempt at following the "once and only once" paradigm. The only possible issue may be with whether or not there is a risk of SQL injection-It's impossible to tell from the example.

FAIL. Again.

Alfred Styrkarsson:

Being a DBA, I'd consider this ok for a small Access or other desktop database, but NOT using bind variables requiring the database server to hard parse every statement sent, this is a receipe for a disaster, placing unneccesary load on the server. But oh well, developers ARE lazy, and this is the proof.

A DBA calling a developer lazy? Isn't that like the pot calling the kettle a racial epithet?

Alfred Styrkarsson:

Being a DBA, I'd consider this ok for a small Access or other desktop database, but NOT using bind variables requiring the database server to hard parse every statement sent, this is a receipe for a disaster, placing unneccesary load on the server. But oh well, developers ARE lazy, and this is the proof.

We don't know how the resulting string is used. Maybe it is used to generate a query object which is then cached. We don't know if the WHERE clause supports positional parameters.
Perhaps there is another method in this class, that returns the DB compiled version...
Or perhaps you are just trolling...

This looks like code from MicroStrategy's DBQuery tool. MSTR is a common abreviation of MicroStrategy, plus the class name is also similar.

Alfred Styrkarsson:

NOT using bind variables

You can't tell that from the example.

Danny:

MSTR is a common abreviation of MicroStrategy

Or for 'a member variable of type string' ...

So I guess the people who don't see anything wrong with this have never heard of stored procedures.

This way the code looks much better without the nasty "s!

Anonymous:

TRWTF is everyone going on about bloody embedded file systems. Childhood aside, since when did endless repetition = humour?

It all started on 2010-01-11, when a post absent of WTF was posted on this very website. The comments started coming in. They were about embedded platforms, and file systems. At first it was frustrating that the same ideas were being posted again and again. Then, it became confusing. As we sat, pressing F5, we could only stare on in horror as more than two hundred readers all contributed their two cents about embedded file systems. To remain sane, all we could do was laugh.

Stored procedures are TRWTF

Ok, it is stupid code and definitly an example of softcoding, but a wtf? nah...

Most importantly, it reveals typos at COMPILE TIME not runtime.

Actually a good thing.

Wolfgang F.:

That is why stored procedures was invented :D

Holy shit, the voice of reason.

operagost:

A strange new world rises from the old: a world of savagery, super science, and new SQL syntax.

No! Only new SQL *keywords*. If you need to change the syntactic structure then you'll need a rewrite. That's the real WTF - this code is far too inflexible.

I don't see anything wrong with it as long as they avoid SQL injection on the WHERE portion.

Justin:

Most importantly, it reveals typos at COMPILE TIME not runtime.

Only the most trivial kind. It doesn't guard against truly stupid things like swapping the WHERE and the SELECT...

The point is really not to "plan for the future", but to prevent typos when writing SQL. I think it's a pretty good idea actually.

svn diff querystring.java

public class DBQueryString
{
protected String mstrSelect;
protected String mstrTable;
protected String mstrWhere;
protected String mstrOrder;
- // maybe I needing later
- public static final String SELECT = "delete ";
+ public static final String SELECT = "select ";
:
public static final String FROM = " from ";
- public static final String WHERE = " where 1 == 1 -- ";
+ public static final String WHERE = " where ";
public static final String AND = " and ";