• Bill C. (unregistered)
    snoofle:
    We change our clothes, jobs and sometimes even spouses. Change can be a good thing. Some say not to fear change, but to embrace it! Wisdom tells us to always be prepared for change. Bill U's company likes to be prepared for change.
    Who's Bill U? Bill C's company was prepared to change clothes when company was present and wife wasn't. Bill C almost had to change jobs because of that.

    Now who changed wives to spouses? If Hilary engaged in husband swapping she'd never make it through the primary.

  • (cs) in reply to Tom
    Tom:
    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'

    That wouldn't return 1/1/2012 00:00:00.000

  • (cs) in reply to dkf
    dkf:
    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.

    so let the boffins that created your RDBMS handle it.

  • JJ (unregistered) in reply to Mason Wheeler
    Mason Wheeler:
    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: <>

    Just to be pedantic, since you used the plural everywhere else, it should be "parentheses."

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

    Haha, it's for an Access database.

    Please unlearn this. The question marks are placeholders for replacement parameters. They are NOT wildcards, and therefore they do not automatically imply Access.

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

    Haha, it's for an Access database.

    Please unlearn this. The question marks are placeholders for replacement parameters. They are NOT wildcards, and therefore they do not automatically imply Access.

    Wait, modern programming languages allow that? That's a worse pattern than referencing an item in a collection blindly by index.

  • urza9814 (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!

    GPS software requires extremely precise timing and needs to take into account things like time changes due to relativity. However, the only thing it's really looking at is how long it takes a signal to get from the satellite to your receiver. SO, you don't really need to worry about things like DST, because you're never going to need hour resolution. Hell, just knowing what second it is within the current minute (and milliseconds and such within that) may be enough. But if you're off by a second or even fractions of a second it may locate you somewhere hundreds of miles away. So for a GPS receiver leap seconds are more important than daylight savings, while in most other applications it's the other way round.

  • Erik (unregistered) in reply to faoileag
    faoileag:
    There are two more interesting things about the code nobody seems to have mentioned so far:

    First, where does "useLiteralCustomerId" come from? It's not a parameter of the methods in which it is used, it's not a member variable... does Java allow global variables?

    Second: CustIdUtil.getCustIdAsString(). This looks like a call to a static method to me, which begs the question: do all customers have the same id?

    The "private final boolean workOnArchive;"-declaration suggests there's a constructor missing in this code snippet... perhaps it sets the variable you're looking for...

    ...however, just like you I reacted to the static CustIdUtil-call. I suspect it's hot wired into some HttpSession or similar... really clarifying code though! (not)

    I use to think of programming as communication. Communication with the computer and user (obviously - or maybe not always that obvious?) AND communication with other programmers.

    Crap like that static call is a good example of gobbledygook-type of communication.

  • Mullet (unregistered)

    It's interesting how this kind of shit is always done by someone coding in Java.

  • qbolec (unregistered) in reply to JArkinstall
    JArkinstall:
    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.

    Well, it doesn't sound THAT easy. It would require writing or more likely: using some existing library for parsing SQL grammar, which doesn't sound like something I'd like to do on each request (provided that PHP is not the fastest runtime in the world and I do not know any good context-free grammar parser written in PHP, and I do not have definition of SQL grammar at hand).

    Unless you meant str_replace(" IS ","<=>",$this->statement), but I really hope you did not, as this is rather stupid.

  • jimm (unregistered)

    I think it's reasonable. This way you're guaranteed not to have typos when you use the constants later. If you type out "WHERE" 100 times it's likely you'll make a typo on one, which won't be caught by the compiler. If you have autocompletion like intellisense, it'll actually make it faster typing the commands later on.

  • Dirk (unregistered)

    ONE_DAY_MINUS_ONE_MILLISEC = 86399999; WTF?

  • Neil (unregistered) in reply to Prof. Foop
    Prof. Foop:
    And in what universe is an outer join represented by "(+)="?
    <LHS> (+) = <RHS> is a right outer join in Oracle; if you want a left outer join it's <LHS> = <RHS> (+) instead. In other words, the (+) is added to the side where the table does not need to have a matching row.

    SQLBase copied that syntax, but went with a slightly different outer join behaviour.

    The advantage of sticking to right outer joins is so that you can easily switch to the Sybase version =* which SQL Server copied before it supported ANSI join syntax.

  • Andrei Rinea (unregistered)

    Smart asses like these created ORMs...

  • easily offended and proud of it (unregistered) in reply to xaade
    xaade:
    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.

    so, you're recommending one should be "not easily offended", in a comment solely dedicated to publicly taking offence regarding whom you deem "the easily offended"? so logicky!

  • VolodyA! V Anarhist (unregistered)

    It could make sense with any software that can interface with 1С (Russian database system). It uses a language that is basically SQL, but with all the strings translated into Russian.

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

Log In or post as a guest

Replying to comment #:

« Return to Article