• (cs) 
    protected static final String BETWEEN = " BETWEEN ? AND ?";

    Haha, it's for an Access database.

  • MatthewIsAnOaf (unregistered)

    protected static final FALSE = true; protected static final I_WANT_TO_DIE_JUST_FROM_READING_THAT = FALSE;

  • (cs) in reply to VeeTwo
    VeeTwo:
    I would like to update the following additional columns, please: - name - lastname - ' WHERE 1=0; SELECT password FROM Users;

    Have you herd of password hash? Also this will not work in Sql Server machine.

  • (cs) in reply to Iggy
    Iggy:
    StringBuilder sql = new StringBuilder(1024); <---- sql.append(UPDATE).append(viewname).append(SET).append(columsForUpdate); if (additionalColumns != null && additionalColumns.length() != 0) { sql.append(additionalColumns); }

    Just wondering how the 1024 will hold the whole string, if there are a lot of additional Columns???

    no one will ever need more than 1024 characters of columns

  • qbolec (unregistered) in reply to VeeTwo
    VeeTwo:
    I would like to update the following additional columns, please: - name - lastname - ' WHERE 1=0; SELECT password FROM Users;
    In what context all these three fragments could be used interchangeably without causing parse error?
  • jay (unregistered) in reply to dwmc
    dwmc:
    TRWTF is assuming that all of your readers are sexually attracted to females and are at all interested in marriage, assuming the option is even available to them. "We change our clothes, jobs and sometimes even wives." Way to annoy at least 2 large groups of people there.

    I take it the two large groups you refer to are: 1. those who have only one suit of clothes; and 2. those who cannot get a job.

  • lolatu (unregistered)

    Roll your own ORM? Oh hells naw! At least this performs better than Doctrine.

  • (cs) 
     protected static final int ONE_DAY_MINUS_ONE_MILLISEC = 86399999;
    This is wrong during DST and leap-seconds. Where do I file a bug?
  • (cs) in reply to chubertdev
    chubertdev:
    protected static final String BETWEEN = " BETWEEN ? AND ?";

    Haha, it's for an Access database.

    Assuming the ?s get replaced, MSSQL uses the same syntax.

  • C-Derb (unregistered) in reply to qbolec
    qbolec:
    VeeTwo:
    I would like to update the following additional columns, please: - name - lastname - ' WHERE 1=0; SELECT password FROM Users;
    In what context all these three fragments could be used interchangeably without causing parse error?
    I think he is simply pointing out the SQL injection vulnerabilities.
  • Paul Neumann (unregistered) in reply to lolatu
    lolatu:
    Roll your own ORM? Oh hells naw! At least this performs better than Doctrine.
    Are you threatening me?
  • Tasty (unregistered) in reply to Musaran
    Musaran:
    How does one use BETWEEN ?

    Why are ISNULL and ISNOTNULL the only ones not using _ naming ?

    Why is MIN's value lowercase ?

    What is the purpose of ONE_DAY_MINUS_ONE_MILLISEC ? Er, let me rephrase that : Is there a legitimate reason to have such value ?

    Sadly, I think the ONE_DAY_MINUS_ONE_MILLISEC is one of the few constants that makes sense. I don't know why they want it, but a numeric constant for the number of milliseconds in a day, or larger time unit, is useful.

  • ih8u (unregistered) in reply to dwmc
    dwmc:
    TRWTF is assuming that all of your readers are sexually attracted to females and are at all interested in marriage, assuming the option is even available to them. "We change our clothes, jobs and sometimes even wives." Way to annoy at least 2 large groups of people there.

    Yeah, I'm naked, and that pissed me off. I don't change clothes. I don't even wear clothes.

    What an insensitive jerk!

    CAPTCHA: uxor -- I wouldn't have put in the captcha except that it is relevant to the troll I'm currently feeding, and I usually do it anyway.

  • (cs)

    If this were C, you could take advantage of the fact that the compiler (or preprocessor?) concatenates adjacent string literals:

    #define SELECT "SELECT "
#define FROM " FROM "
#define WHERE " WHERE "

const char *query = SELECT "foo, bar" FROM "my_table" WHERE "foo > 42";

    A great way to write code that looks fine at first glance to someone who doesn't know the language, but makes future maintainers scream WTF!?

  • (cs) in reply to TroelsL
    TroelsL:
    This will only solve syntax changes, not semantic changes. Obviously, there is a need to code a more elaborate framework that will handle that case also.
    Not even syntactic changes, as the code would have to be changed anyway, but only orthographic (aka spelling) changes. And I'm surprised no one commented on 
    FETCH_SIZE_1000 = 1000;
    yet.
  • (cs) in reply to SamC
    SamC:
     protected static final int ONE_DAY_MINUS_ONE_MILLISEC = 86399999;
    This is wrong during DST and leap-seconds. Where do I file a bug?
    We have a winner! The problem with all the other constants is that they obscure the subtle problems with their obvious stupidity. (Leap seconds might not actually be a problem in practice, as there's a lot of code that assumes all minutes are 60 seconds long and so OSes adapt for you by default, but DST changes must be handled. Unless you're writing GPS software, where it's closer to the other way round.)

    So we need to change all those other constants so they are looked up in a web service running on the Cloud. With no caching, since the Cloud is obviously scalable and who knows when the “constants” might have to change…

  • (cs) in reply to Sutherlands
    Sutherlands:
    chubertdev:
    protected static final String BETWEEN = " BETWEEN ? AND ?";

    Haha, it's for an Access database.

    Assuming the ?s get replaced, MSSQL uses the same syntax.

    If true, that'd be a whole different WTF. I didn't even think of that being possible, since it should just be " BETWEEN @value1 AND @value2", which is what I've always used.

  • (cs) in reply to dkf
    dkf:
    SamC:
     protected static final int ONE_DAY_MINUS_ONE_MILLISEC = 86399999;
    This is wrong during DST and leap-seconds. Where do I file a bug?
    We have a winner! The problem with all the other constants is that they obscure the subtle problems with their obvious stupidity. (Leap seconds might not actually be a problem in practice, as there's a lot of code that assumes all minutes are 60 seconds long and so OSes adapt for you by default, but DST changes must be handled. Unless you're writing GPS software, where it's closer to the other way round.)

    So we need to change all those other constants so they are looked up in a web service running on the Cloud. With no caching, since the Cloud is obviously scalable and who knows when the “constants” might have to change…

    Still cleaner than any Oracle SQL date statement.

    WHERE CreatedDate BETWEEN @Date1 AND DATEADD(millisecond, -1, DATEADD(day, 1 @Date2))
  • Peter (unregistered) in reply to dkf
    dkf:
    DST changes must be handled. Unless you're writing GPS software, where it's closer to the other way round.
    I (honestly) can't work out what this means. If you're writing GPS software, TSD changes must be handled? If you're writing GPS software, DST changes must not be handled? If you're handling DST changes, GPS software must not be written? If you're handling DST changes, GPS software must be written? Help!
  • Paul Neumann (unregistered) in reply to Peter
    Peter:
    dkf:
    DST changes must be handled. Unless you're writing GPS software, where it's closer to the other way round.
    I (honestly) can't work out what this means. If you're writing GPS software, TSD changes must be handled? If you're writing GPS software, DST changes must not be handled? If you're handling DST changes, GPS software must not be written? If you're handling DST changes, GPS software must be written? Help!
    Something cleverly weaving a suggestion for a GPSTD acronym/abbr.
  • Simon (unregistered) in reply to Sutherlands
    Sutherlands:
    Unisol:
    I can understand the desire to move SQL literals to constants (benefits: interning/autocompletion/cleaner looking code),
    Er, no, at least not on two of them. You may get autocompletion (is that really going to make a difference?), but it's definitely not cleaner looking code and literal strings are interned anyway.

    Not so much autocompletion, and more about compile-time checking, I think. If you mistype INSERT_INTO, the IDE will tell you about it immediately. If you mistype "insert into", you don't find your mistake until someone tries to run it.

    Now, I'm certainly not suggesting that this is a good idea. But I suspect the practice has evolved to protect against less competent coders... I know we have things like functions for testing if a string is null or empty - not for brevity of code, but because developers couldn't be trusted not to screw it up...

  • Vlad Patryshev (unregistered)
    StringBuilder sql = new StringBuilder(1024);

    I believe this is enough for year 2013 (as well as for year 2000) to declare the author a pathetic idiot and stop reading further.

  • Ben (unregistered) in reply to xaade

    Even better, put the definitions in another database

  • Prof. Foop (unregistered)

    The 'braces' will not match: sql.append(MIN).append(colums[0]).append(BRACE_END );

    And a STAR will always be "*", but the symbol used for ALL_COLUMNS might change.

    And in what universe is an outer join represented by "(+)="?

    Is colums the slimy creature from Lord of the Rings?

  • enterprising character (unregistered)

    Not nearly generic enough with only SPACE and DOT, should be more like :

    public abstract class DAOJDBCBase { protected static final String A = "A"; protected static final String B = "B";

    or for extra points on your future c.v. you could use Spring dependency injection to read these values in from an XML configuration file, in case these values differ in your development or production environments.

  • modifiable lvalue (unregistered)

    SPACE MAKES IT GO FASTER!

  • Mr Not Easily Offended (unregistered) in reply to xaade

    It's not about being "easily offended". It's about not forever portraying programming as a male-only field. Statements like "and sometimes even wives" just add tiny grain of support to a massive historical bias against females coders. Tiny in itself, but the overall effect is not good and not one we should perpetuate.

  • (cs)

    As is often the case, a good idea poorly executed. It is not about the literals changing, it is about getting compile errors for a "typo" in building a statement rather than a runtime error. I have done similar (but different) items, such as declaring types for the various clauses, and doing simple (not robust) validations (such as delete taking a from clause and a where clause - no where, no delete!)

  • Mr Not Easily Offended (unregistered) in reply to xaade
    xaade:
    dwmc:
    TRWTF is assuming that all of your readers are sexually attracted to females and are at all interested in marriage, assuming the option is even available to them. "We change our clothes, jobs and sometimes even wives." Way to annoy at least 2 large groups of people there.

    I've lost all patience for the easily offended. So much so that I have a one gesture for them, and it only needs one finger.

    It's not about being "easily offended". It's about not forever portraying programming as a male-only field. Statements like "and sometimes even wives" just add tiny grain of support to a massive historical bias against females coders. Tiny in itself, but the overall effect is not good and not one we should perpetuate.

  • egor (unregistered)

    Whoooaaaa, looks EXACTLY like one of the projects I worked on. Even though my job was to GET RID OF THIS CRAP back in 2004, right, that's almost 10 years ago, and replace the most of it with Hibernate, it appears they still have that dark legacy.

    Russian hosting provider slash news agency, amirite?

  • George (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    Musaran:
    How does one use BETWEEN ?

    Why are ISNULL and ISNOTNULL the only ones not using _ naming ?

    Why is MIN's value lowercase ?

    What is the purpose of ONE_DAY_MINUS_ONE_MILLISEC ? Er, let me rephrase that : Is there a legitimate reason to have such value ?

    There might or might not be a legitimate reason to have a named constant that contains a number that represents that amount of time, but ONE_DAY_MINUS_ONE_MILLISEC doesn't specify the units.

    It is reasonable (aside perhaps from SQL not supporting it) to expect a constant with this name to be 86399999000 (microseconds) or 86399.999 (seconds) or even 863999990000 (hectananoseconds, the increment of time in NTFS timestamps) or 0,999999988425926 (days, approximately).

    And it's a bad name for another reason - it doesn't explain what it is for. As written, the name describes (aside from the lack of units) what it represents at the most literal level, but why would I need such a thing? As it is, it is just as bad as our old friends:

    const int ZERO = 0;
const int ONE = 1;
    Uhm, at it's worst it IS our old friend....

    Let's work out what he means. The MILLISEC looks like a unit to me, so we'll take that off, so it's ONE_DAY_MINUS_ONE in milliseconds. Yup, looks like it should be 0 to me.....

  • Millie (unregistered) in reply to dwmc
    dwmc:
    TRWTF is assuming that all of your readers are sexually attracted to females and are at all interested in marriage, assuming the option is even available to them. "We change our clothes, jobs and sometimes even wives." Way to annoy at least 2 large groups of people there.
    For F's sake, has the world really gotten that sensitive? I'm sure any sane woman would realise that the article is written by a male and s/wives/husbands/g (of course there's going to be comments now how there is no such thing as a sane woman).

    As for the gay community, everyone knows that since Alan Turing we haven't had any gay computer experts. but seriously, I don't see that they'd be any more offended than the unemployed person reading it thinking that he doesn't get to change jobs - or the nudist offended that they never get the chance to change clothes.

    Clearly you have just incited WWVII on this site....

  • Tom (unregistered) in reply to chubertdev
    chubertdev:
    dkf:
    SamC:
     protected static final int ONE_DAY_MINUS_ONE_MILLISEC = 86399999;
    This is wrong during DST and leap-seconds. Where do I file a bug?
    We have a winner! The problem with all the other constants is that they obscure the subtle problems with their obvious stupidity. (Leap seconds might not actually be a problem in practice, as there's a lot of code that assumes all minutes are 60 seconds long and so OSes adapt for you by default, but DST changes must be handled. Unless you're writing GPS software, where it's closer to the other way round.)

    So we need to change all those other constants so they are looked up in a web service running on the Cloud. With no caching, since the Cloud is obviously scalable and who knows when the “constants” might have to change…

    Still cleaner than any Oracle SQL date statement.

    WHERE CreatedDate BETWEEN @Date1 AND DATEADD(millisecond, -1, DATEADD(day, 1 @Date2))
    WHERE CreatedDate > '01Jan2012' and CreatedDate < '02Jan2013'
  • milk (unregistered) in reply to Mr Not Easily Offended
    Mr Not Easily Offended:
    It's not about being "easily offended". It's about not forever portraying programming as a male-only field. Statements like "and sometimes even wives" just add tiny grain of support to a massive historical bias against females coders. Tiny in itself, but the overall effect is not good and not one we should perpetuate.
    Why is it people jump up in a huff when a male writer's/blogger's "maleness" comes out, but are unconcerned when we see the opposite behaviour froma female?

    It's interesting that the quest for gender-equality seems to be skewed toward feminism, rather than toward gender-equality.

  • Teh Supa Coda (unregistered) in reply to TheCPUWizard
    TheCPUWizard:
    As is often the case, a good idea poorly executed. It is not about the literals changing, it is about getting compile errors for a "typo" in building a statement rather than a runtime error. I have done similar (but different) items, such as declaring types for the various clauses, and doing simple (not robust) validations (such as delete taking a from clause and a where clause - no where, no delete!)
    I just get things right first time.
  • Bilongda Mick (unregistered) in reply to Mr Not Easily Offended
    Mr Not Easily Offended:
    xaade:
    dwmc:
    TRWTF is assuming that all of your readers are sexually attracted to females and are at all interested in marriage, assuming the option is even available to them. "We change our clothes, jobs and sometimes even wives." Way to annoy at least 2 large groups of people there.

    I've lost all patience for the easily offended. So much so that I have a one gesture for them, and it only needs one finger.

    It's not about being "easily offended". It's about not forever portraying programming as a male-only field. Statements like "and sometimes even wives" just add tiny grain of support to a massive historical bias against females coders. Tiny in itself, but the overall effect is not good and not one we should perpetuate.

    How fortunate indeed must we be to have people that bring such gross errors in judgement to light. Honestly, it's like on shows such as "60 minutes" where they uncover something bad "in the public interest" which only spurs further interest (eg I'll bet stories about the evils of SilkRoad increase the success of SilkRoad; or stories about hoon drivers increases hoon behaviour on the roads). If you are truly concerned about such abhorrent behaviour being perpetuated, then perhaps starting argument about it in a public forum is not the most sensible approach.
  • (cs)

    This is more secure than concatenating raw SQL because we're concatenating constants! Constants don't change, so users can't hack them!

  • Norman Diamond (unregistered)

    This style is good for localization:

    protected static final String 格好開始 = " (";
    And let's not forget:
    // Must be 1536
protected static final int FETCH_SIZE_1000 = 4096; // 2048 // 1536 // 1280 // 1000

  • Squidularmy (unregistered)

    This is not extendable enough. The alphabet should be stored in a char array and referenced. In fact, an ArrayList would make more sense, in case another letter(s) is added to the alphabet later.

  • ares (unregistered) in reply to Musaran

    What is the purpose of ONE_DAY_MINUS_ONE_MILLISEC ? Er, let me rephrase that : Is there a legitimate reason to have such value ?

    if the millisecond is under the resolution of given data, it would be legal to use it for defining non-overlaping intervals. but undertanding the difference between < > and <= >= also helps ;-)

  • Chris (unregistered) in reply to Customer

    Then that's the real WTF. What about the end of year (31.12) that doesn't have exactly 24 hours, but maybe a second less? What about days with 23 or 25 hours when daylight-saving is on?

  • ares (unregistered) in reply to Vlad Patryshev
    Vlad Patryshev:
    StringBuilder sql = new StringBuilder(1024);

    I believe this is enough for year 2013 (as well as for year 2000) to declare the author a pathetic idiot and stop reading further.

    Fun fact: In most languages something like this (growable collections, whatever-builders) and certainly StringBuilder in Java, the number is not a limit but a hint concerning initial allocation. Respective classes also know how to grow efficiently (wrt allocations, copying and freeing memory).

    Next time you feel like you know something, you might point it out in different style, so you won't look like pathetic idiot even in the case you are right ...

  • (cs) in reply to chubertdev
    chubertdev:
    Still cleaner than any Oracle SQL date statement. 
    WHERE CreatedDate BETWEEN @Date1 AND DATEADD(millisecond, -1, DATEADD(day, 1 @Date2))
    That's ugly, but doesn't have the bug that defining a day to be a fixed number of milliseconds implies. Time handling is always much harder than it appears to be.
  • Spudley (unregistered) in reply to herby
    herby:
    ForFoxSake:
    Why? WHy?? WHY???
    Because, BEcause, BECAUSE!!

    This is horrible horrible horrible.

    But I guess that the original author had some thought that it might make things easier by giving him some warped kind of syntax completion/highlighting of SQL code in his IDE.

    That doesn't make it any better, but maybe, just perhaps, its a clue as to how these sorts of things happen.

  • JArkinstall (unregistered) in reply to qbolec
    qbolec:
    do you know that : 1. "INSERT IGNORE " known from MySQL is written "INSERT OR IGNORE " in Sqlite? 2. "<=>" operator from MySQL is written " IS " in Sqlite? 3. Some people suggest to use Sqlite (with memory engine) for (unit/integration) testing apps which then run in production environment with MySQL? 4. can you imagine the fun you have, the day you realize you have to define 
    <?php
class PDOSqlite extends PDOEx
{
  public function insert_ignore_command(){
    return 'INSERT OR IGNORE';
  }
  public function strong_equality_operator(){
    return ' IS ';
  }
}
?>
    even though you know people will laugh at you?

    No, I can't imagine that day. Because it will never, ever happen. It is a terrible, terrible way of approaching a rather easy problem.

    Is it THAT hard to extend PDO to run queries through a string-modifying function instead, with the extending MySQL class returning the initial string, and the SQLITE replacing "<=>" with "IS", and other basic syntax changes?

    If you find yourself completely mashing up a process just to add a little bit of flexibility, you should consider closing your IDE for good, and getting a job in government instead.

  • (cs)
    We change our clothes

    Don't be so sure about that.

  • (cs)

    This is why I laugh at people who's against ORMs. At the end you'll implement your own crappy, bug infested ORM which will handle like crap and become unsustainable.

    The good thing is that we'll probably keep getting more and more WTFs like this one.

  • Paula (unregistered)

    private static final boolean IS_ENTERPRISEY = true;

    private static final boolean IS_FRIST_DOUCHE = true;

    private static final String CAPTCHA = "validus";

  • Norman Diamond (unregistered) in reply to Squidularmy
    Squidularmy:
    This is not extendable enough. The alphabet should be stored in a char array and referenced. In fact, an ArrayList would make more sense, in case another letter(s) is added to the alphabet later.
    Letters are added to the alphabet all the time. On a machine (or more accurately, on an implementation) where char is 32 bits, a char array could handle them. On some implementations a wchar_t array could handle them. The change from old style wchar_t to Unicode wchar_t was a big change, but once you get over that hurdle it's easier to provide future-proofing for further additions to the Unicode alphabet.
  • (cs) in reply to Geoff
    Geoff:
    I am not sure its exactly a WTF to make some SQL reserved words constants. BRACE_BEGIN though is going a bit far. Especially when its actually a open parenthesis. One would normally expect it to be a brace '{'.
    Yes, thank you! It drives me up the wall when people talk about the enclosing symbol characters with the wrong names. We're supposed to be working with precision language as programmers, aren't we?

    PARENTHESIS: () BRACES: {} BRACKETS: [] ANGLE BRACKETS: <>

Leave a comment on “The More Things Change...”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article