Unique Paranoia



  • I stumbled upon a small (but zesty!) python WTF today, thought I would share.

    First a little background. This is Python running with SQLite as a DB. Therefore we should all know this (which the programmer in question here obviously did not understand): 

    @http://www.sqlite.org/autoinc.html said:

    In SQLite, every row of every table has an integer ROWID. The ROWID for each row is unique among all rows in the same table.

     Entire function for retrieval:

    def GetAll(id):
      """
      Returns the entire player row
      """
      global cur;
      cur.execute("SELECT * FROM player WHERE rowid = ? LIMIT 1", (id,));

      return cur.fetchone();

    So, we have made a query using a WHERE clause on a unique column. We have then limited the query to 1 result (???). And then on top of that, we fetchone() to make triple sure that we only return one row. Brilliant!

    On top of this, we don't bother to close the cursor... 

     

    I am not sure what the programmer was thinking here, but I guess they figure that just in case that unique row suddenly returns multiple results and the LIMIT statement fails, this application will be rock solid!

    For extra zestiness, note the abundance of semi colons... In python!

    The best part is that this is a common theme throughout the DB code.



  •  This one doesn't seem so bad. My SQLite experience consists of about an hour of fiddling with it before realizing that it didn't fit my needs for anything I was working on, but one of the systems I have to maintain consists of a medium-sized, horribly-designed MySQL database and a Java component that somehow managed to hose up the tables enough to enter supposedly-unique keys multiple times.

    The sad part is, one of the changes I made while tracking down the problem was to force a function to do the following:

    1. "SELECT `blah blah blah` FROM hosedtable WHERE uniquekey = 'blah'"

    2.  if (returned_row_count > 1){ email.send("Table is hosed again");}

    ...and if I had left line #2 in there I'm pretty sure I would eventually see that code on TDWTF too. Anyway, the point here is that I understand being paranoid about it, as in my experience, "unique" keys aren't always so, and it's easy to get in the habit of writing code that says something to the effect of, "...and please, for crying out loud, give me only ONE GOD DAMN ROW!"



  • @durendal.mk3 said:

    2.  if (returned_row_count > 1){ email.send("Table is hosed again");}

    ...and if I had left line #2 in there I'm pretty sure I would eventually see that code on TDWTF too.

    I'm not so sure.  To another party your code will obviously be catering for perceived failings in the software and actively informing someone of the problem.  MPS's example (if it is indeed for the same reasons) just tries to brush the problem under the carpet and get a (possibly spurious) result anyway?  Arguable.



  • Using fetchone is not a wtf, it returns a single row instead of a list.

    The limit statement is unnecessary, but just a minor mistake. Cursor is made global, so it shouldn't be closed (it being global is a bit nasty though). The semicolons are quite strange though, seems the writer was not familiar with python. 



  • @durendal.mk3 said:

     This one doesn't seem so bad. My SQLite experience consists of about an hour of fiddling with it before realizing that it didn't fit my needs for anything I was working on, but one of the systems I have to maintain consists of a medium-sized, horribly-designed MySQL database and a Java component that somehow managed to hose up the tables enough to enter supposedly-unique keys multiple times.

    Was this a distributed DBMS system? If so, I'd understand the possibility of key duplications. If not, then I'd point out the "horribly-designed" WTF as setting either a UNIQUE constraint or actually using the key as a PRIMARY KEY would avoid the duplicates.

    The Real WTF on this example would be that even if it was possible to have duplicate rowId's, the overworked checking would not alert the user that such a case exists!



  • @danixdefcon5 said:

    @durendal.mk3 said:

     This one doesn't seem so bad. My SQLite experience consists of about an hour of fiddling with it before realizing that it didn't fit my needs for anything I was working on, but one of the systems I have to maintain consists of a medium-sized, horribly-designed MySQL database and a Java component that somehow managed to hose up the tables enough to enter supposedly-unique keys multiple times.

    Was this a distributed DBMS system? If so, I'd understand the possibility of key duplications. If not, then I'd point out the "horribly-designed" WTF as setting either a UNIQUE constraint or actually using the key as a PRIMARY KEY would avoid the duplicates.

    The Real WTF on this example would be that even if it was possible to have duplicate rowId's, the overworked checking would not alert the user that such a case exists!

    Even for distributed systems I think this would still be a WTF. I'm quite sure modern DBMS's can be set up to avoid key replication in distributed environments.


  • [quote user="Renan "C#" Sousa"]Even for distributed systems I think this would still be a WTF. I'm quite sure modern DBMS's can be set up to avoid key replication in distributed environments.[/quote] 

    Yes, but the beauty of this thread so far are all the people arguing against trusting a unique rowid.

    TRWTF always emerges.



  • @danixdefcon5 said:

    Was this a distributed DBMS system?
     

    No, it was all on one server, and replicated up to a backup server for disaster recovery purposes. To this day, I still don't know how duplicates made it in, but upgrading from MySQL version 3 to MySQL version 5, and making an attempt at normalization solved the problem. Even if I had an unreasonable hatred of MySQL's replication feature for a long time after (having to restart replication multiple times a day because it keeps breaking with a "Duplicate key" error tends to grate on your nerves after a while).

    @danixdefcon5 said:

    The Real WTF on this example would be that even if it was possible to have duplicate rowId's, the overworked checking would not alert the user that such a case exists!

    Agreed; I doubt there is there a situation where a database would have duplicate keys and it wouldn't be a critical issue.

    @MasterPlanSoftware said:

    Yes, but the beauty of this thread so far are all the people arguing against trusting a unique rowid.

    I'd be surprised if a thread managed to stay on topic for longer than one post.

     



  • @durendal.mk3 said:

    I'd be surprised if a thread managed to stay on topic for longer than one post.
     

    Not sure how this had anything to do with what you quoted, but this thread is still on topic so far. 

    Not sure what you are hoping to achieve here, but you and soviut seem to be the only trying to derail anything.



  • @MasterPlanSoftware said:

    We have then limited the query to 1 result (???).
     

     There have been databases where an explicit limit can be used as an optimization technique. Granted, this hasn't been true for things with a unique constraint in ages in any real Database, but perhaps this developer is used to a system so stupid? Or they are in the habit of doing a LIMIT 1 whenever they know they want one row instead of thinking "can the database reasonably optimize this?"

     It doesn't seem to be a horrible habit of getting into -- much better than the alternative. Would you rather that the developer forget to limit 1 if doing something like sorting by date, then only grabbing one row?

     .fetchone() is not a wtf for the reasons outlined above.

    So, really, the only real WTF is a global cursor, with a few lower-cased wtfs that don't deserve to have been mentioned except for possibly barely, under your breath, as you "fixed" it and moved one quietly.



  • @MasterPlanSoftware said:

    Not sure what you are hoping to achieve here
     

    Pointing out the fact that your original post isn't a WTF, not for the reason you presented. While one wouldn't expect a DBMS to allow duplicate keys into a table, it can happen, and this is a case where such paranoia would be justified. As pointed out, TRWTF is that in such a situation the code you presented picks a row and shows it, instead of falling back to some sort of an error--the programmer foresaw a situation where database integrity could fail and thought the acceptable solution would be to silently pick something at random when the chances of choosing correctly are at best 50%.

    You evidently seem to think the best course of action in that situation is to just use the first row returned (the same mistake made by the original programmer). Either that, or you trust your DBMS too much and think there's no way you can have duplicate keys, ever. 

    The best course of action would be to at least log an error or send an email, rollback in case you have other queries in that transaction that depend on this one working (and you are using SQLite's transactional features), and throw an exception (not necessarily in that order).

    @MasterPlanSoftware said:

    but you and soviut

    I'm not entirely clear on what my and soviut's posts have in common.



  • @durendal.mk3 said:

    Pointing out the fact that your original post isn't a WTF, not for the reason you presented. While one wouldn't expect a DBMS to allow duplicate keys into a table, it can happen, and this is a case where such paranoia would be justified. As pointed out, TRWTF is that in such a situation the code you presented picks a row and shows it, instead of falling back to some sort of an error--the programmer foresaw a situation where database integrity could fail and thought the acceptable solution would be to silently pick something at random when the chances of choosing correctly are at best 50%.
    Why do you insist on failing at reading? MPS clearly quotes in his OP that "[i]n SQLite, every row of every table has an integer ROWID. The ROWID for each row is unique among all rows in the same table." (Emphasis mine) So, no, it isn't possible to have duplicate keys.



  • @durendal.mk3 said:

    You evidently seem to think the best course of action in that situation is to just use the first row returned
     

    It can only return 1 row, with or without the LIMIT 1. Arguing anything different makes you stupid.

    @durendal.mk3 said:

    Either that, or you trust your DBMS too much and think there's no way you can have duplicate keys, ever. 

    Yes, I trust my DBMS to maintain the RowID as unique. The fact you are arguing against this is amazing, and makes you way stupider than the idiot who wrote the code in my OP.

    @durendal.mk3 said:

    The best course of action would be to at least log an error or send an email,

    And how would you recommend that happens with the code in the OP? Using LIMIT 1 is certainly not going to help you achieve that goal!

     @durendal.mk3 said:

    I'm not entirely clear on what my and soviut's posts have in common.

    You are both trying to troll. Especially your post. No one can be stupid enough to really think that RowID is going to spontaneously not be unique. And I cannot believe that their solution to this would be to think LIMIT 1 would be a valid solution to this.



  • @bstorer said:

    So, no, it isn't possible to have duplicate keys.
     

    It surely shouldn't be. And I've never seen it happen personally. I'm looking at this from my standpoint and assuming that the DBMS does its job. Others have said that they have seen some version of an unspecified (I think) DBMS fail at this. Assuming they they are not lying (and I have no reason to assume this), this is one possible reason the developer might have written the above code in the way that they did. And yes, this leaves some WTFs (strange failure mode for an anticipated failure case) which others have been pointing out.



  • @negativeview said:

    It surely shouldn't be. And I've never seen it happen personally. I'm looking at this from my standpoint and assuming that the DBMS does its job. Others have said that they have seen some version of an unspecified (I think) DBMS fail at this. Assuming they they are not lying (and I have no reason to assume this), this is one possible reason the developer might have written the above code in the way that they did. And yes, this leaves some WTFs (strange failure mode for an anticipated failure case) which others have been pointing out.

     

    Even if you could argue that it could return duplicate rows (it cannot) the fetchone() would solve this issue. Also, this would be the worst way to get around this issue if you were truly trying to write defensively. It would specifically just ignore the issue and 'guess' by returning the first duplicate.

     

    This is a very stupid thing to do, and it is even stupider that people would actually argue for this.



  • @negativeview said:

    Assuming they they are not lying (and I have no reason to assume this), this is one possible reason the developer might have written the above code in the way that they did.
    If you can't trust the database to meet its own invariants, why are you using it? This isn't defensive programming, where you check for some obscure error condition that should never happen but could, this is checking for things it says aren't possible. At that point, shouldn't you be checking that fetchone returns only one record? And then that the data hasn't disappeared since you called fetchone? Where do you stop checking for the impossible?



  • @MasterPlanSoftware said:

    Even if you could argue that it could return duplicate rows (it cannot) the fetchone() would solve this issue. Also, this would be the worst way to get around this issue if you were truly trying to write defensively. It would specifically just ignore the issue and 'guess' by returning the first duplicate.

    This is a very stupid thing to do, and it is even stupider that people would actually argue for this.

     

    MPS, where did I argue for this at all? Where did anyone say it was a GOOD idea? They have simply debated possible thought processes leading to this code. Even the person saying that their DBMS has screwed up the ids admits that it was a short-lived problem that they don't know how to replicate, merely offering it as a possible reason that the original developer was that paranoid about What Cannot Happen. I have said three things:

    1)  It may have been an attempt at optimization, as I've had to do similar (though not with a unique constraint) things for that reason in the past.

    2) Using LIMIT 1 reflexively when you only want one row is better than not using it, fetching one row, then moving on.

    3) People giving justifications do not necessarily believe that these "reasons" provide more benefit than downfall. They're not necessarily saying "the original code is BRILLIANT! WHY ARE YOU QUESTIONING IT?!" They're simply saying "this might be the thought process of the original developer..."

    I also find it very telling that you're already pulling out both "troll" and "stupid." This post was less WTF-worthy than 90% of the ones that I see you criticize for the same reason. I mean, what is the side-effect of this? Crippling performance? Completely unmaintainable?

    No. The function does its job perfectly. Its big WTF moment is that it makes the sql server do a little more work at parsing a bit that should be optimized out. It even uses parameterized queries. WTF-worthy this is not, no matter how many times you call people stupid or accusing others of trolling.



  • @bstorer said:

    @negativeview said:
    Assuming they they are not lying (and I have no reason to assume this), this is one possible reason the developer might have written the above code in the way that they did.
    If you can't trust the database to meet its own invariants, why are you using it? This isn't defensive programming, where you check for some obscure error condition that should never happen but could, this is checking for things it says aren't possible. At that point, shouldn't you be checking that fetchone returns only one record? And then that the data hasn't disappeared since you called fetchone? Where do you stop checking for the impossible?

    My God, can people not understand that hypothesizing about a thought process does not mean that I believe it?

     I got it, the developer wrote it that way because Xenu told him to. Now I'm a scientologist. I admit that some people believe in Xenu, therefore, I must as well.



  • @negativeview said:

    1)  It may have been an attempt at optimization, as I've had to do similar (though not with a unique constraint) things for that reason in the past.
     

    It is performing a query on a unique column. There is no more optimization than that.

    @negativeview said:

    2) Using LIMIT 1 reflexively when you only want one row is better than not using it, fetching one row, then moving on.

    Using something reflexively is not an excuse. Ever. The unique portion of this query is verified in triplicate. It is just stupid.

    @negativeview said:

    They're simply saying "this might be the thought process of the original developer..."

    Actually, saying this isn't a WTF is surprisingly stupid. And that is what I am calling you on.

    @negativeview said:

    I also find it very telling that you're already pulling out both "troll" and "stupid."

    Again, the point of view that this isn't a WTF is stupid. Also, the two posters I called trolls, were in fact trolling in the posts I called them on.

    @negativeview said:

    This post was less WTF-worthy than 90% of the ones that I see you criticize for the same reason. I mean, what is the side-effect of this? Crippling performance? Completely unmaintainable?

    It is a WTF because it verifies THREE times that there will be one row returned. It is stupid, and it shows an amazing amount of ignorance in the developer for not trusting the RowID to be unique in the first place.

    This cannot even be compared with the lolcat crap that has been posted recently.

    It is a small WTF, but I admitted that in my first sentence in my OP. It is still a WTF though, and has spawned a great reaction of stupid people defending this kind of behavior. That is what our forum is all about. so this thread is actually going perfectly.

     @negativeview said:

    No. The function does its job perfectly.

    It can 'do it's job' just fine, but when you look at the code and think about what it is doing, if you don't say "WTF?" to yourself then you should be writing code or working with databases. And that is the definition of the sidebar.



  • @MasterPlanSoftware said:

    It is performing a query on a unique column. There is no more optimization than that.

    I agree that it should be that way. Though unable to find it at the moment (and thus I shall drop this line of thinking), I am convinced that there was a release of a major DB that failed to optimize this away, however. Rather a bug or a known limitation of the time, I am convinced that it not only existed, but I used that release.

    @MasterPlanSoftware said:


    @negativeview said:

    2) Using LIMIT 1 reflexively when you only want one row is better than not using it, fetching one row, then moving on.

    Using something reflexively is not an excuse. Ever. The unique portion of this query is verified in triplicate. It is just stupid.

    Tell that to everyone that claims that you should always always always check the return value of all system calls. Doing things that give Java a bad name like catching, then throwing an exception that winds up bubbling up to the user is stupid and is a logical side-effect of this message being preached so loudly for so long, but it's still a good lesson. There are some things that you wind up doing by reflex because it's always a good idea. Adding LIMIT 1 to a query when you only want one row is NOT horrible to put on that list.

    @MasterPlanSoftware said:


    @negativeview said:

    They're simply saying "this might be the thought process of the original developer..."

    Actually, saying this isn't a WTF is surprisingly stupid. And that is what I am calling you on.

    Your rebuttal seems to not be at all related to what I said above. In that quote I don't even hint that it's not a WTF, let alone outright say it. So if I were a less mature person, I'd probably call YOU stupid right now for THAT.

    @MasterPlanSoftware said:


    @negativeview said:

    I also find it very telling that you're already pulling out both "troll" and "stupid."

    Again, the point of view that this isn't a WTF is stupid. Also, the two posters I called trolls, were in fact trolling in the posts I called them on.

    Nobody said that this wasn't a lower-case wtf. It's simply not tdwtf worthy. It's surely not worth calling anyone stupid over, and is less of a WTF than half the posts you run around yelling at people for posting on here that don't meet your strangely-defined standards.

    @MasterPlanSoftware said:


    @negativeview said:

    This post was less WTF-worthy than 90% of the ones that I see you criticize for the same reason. I mean, what is the side-effect of this? Crippling performance? Completely unmaintainable?

    It is a WTF because it verifies THREE times that there will be one row returned. It is stupid, and it shows an amazing amount of ignorance in the developer for not trusting the RowID to be unique in the first place.

     You're counting the use of .getone() as verifying that it only returns one row? When cur is global. Granted, it would be a wtf to call that function then call cur.getone() again, but the use of global variables means that getone doesn't actually verify anything about the query (the function, yes). You're down to two. The fact that rowid is a magical row in sqlite is hardly universal knowledge. I didn't know that off the top of my head, with years of experience in closely related fields (mysql, postgres, a little oracle, etc). I should be able to tell by the name of the row, sure, but I didn't _know_ off the top of my head. LIMIT 1 is in this case redundant (getone() is not, quit arguing that) but adds a trivial amount of overhead and might make the intent of the code a little more clear for someone coming from a much more common sql solution.

     I'll agree with you that this solution is less than optimal. I wouldn't have put a LIMIT 1 on there. I'm looking at roughly equivilent code here that doesn't have a LIMIT 1. But this sort of griping seems akin to someone posting on here saying that the entire WTF is a lack of indentation. Or that the entire wtf is that a single variable is named 'foo'.

    @MasterPlanSoftware said:


    This cannot even be compared with the lolcat crap that has been posted recently.

    Maybe I don't spend all day on here, but I haven't seen any LOLCat stuff posted. I've seen a few things that don't qualify as a WTF. I've seen some things that are mild WTFs, and I've seen a few amusing things. The thing they all had in common was that you would jump in and bash someone in that thread for something. If not for the mildness of their WTF, then for quoting habits or their perceived level of intelligence. I normally wouldn't jump in and bash people (look at my post history!, I ignored you when you tried to bash me for my first post here, having already read long enough to know that you would bash me no matter what I said) but the level of your own hypocriticalness is astounding.

    @MasterPlanSoftware said:


    It is a small WTF, but I admitted that in my first sentence in my OP. It is still a WTF though, and has spawned a great reaction of stupid people defending this kind of behavior. That is what our forum is all about. so this thread is actually going perfectly.

    NOBODY has said that this is good behavior. NOBODY has defended this in as so many words. All we have said is that you're being silly for posting this in a forum for deriding actual problematic code.

    @MasterPlanSoftware said:


     @negativeview said:

    No. The function does its job perfectly.

    It can 'do it's job' just fine, but when you look at the code and think about what it is doing, if you don't say "WTF?" to yourself then you should be writing code or working with databases. And that is the definition of the sidebar.

     

    I don't say WTF. I would quietly replace it. Or, to dredge up the very first thing that you ever said to me, when I posted my first WTF (much bigger than yours, I might add):

     @MasterPlanSoftware said:

    If you could have implemented this in 5 lines, then what is the big issue? Rewrite it in 5 lines, pretend it was a huge problem, charge for time, and move on with your life. Sounds like an easy project to me!

    Making the code only check for things once seems like an easy project to me! Charge for your time (is THAT why you're on this site constantly?) and move on with your life.



  • @negativeview said:

    There are some things that you wind up doing by reflex because it's always a good idea. Adding LIMIT 1 to a query when you only want one row is NOT horrible to put on that list.
     

    Verifying that a unique value is unique 3 times is stupid. Sorry, but you are wrong. It goes against all good logic no matter how you (lamely) try and justify it.

    @negativeview said:

    It's surely not worth calling anyone stupid over,

    It sure is.

    @negativeview said:

    and is less of a WTF than half the posts you run around yelling at people for posting on here that don't meet your strangely-defined standards.

    Ahhh, now it comes out, you are upset with my post because you don't like other posts being called out.

    Try and understand this: My treatment of other posts has zero to do with this post. If you can't get over your personal feeling towards me, that is ok, but don't pollute the forums with it.

    @negativeview said:

    The thing they all had in common was that you would jump in and bash someone in that thread for something. I normally wouldn't jump in and bash people (look at my post history!, I ignored you when you tried to bash me for my first post here, having already read long enough to know that you would bash me no matter what I said) but the level of your own hypocriticalness is astounding.

    Again, ad hominem attacks only pollute the forum. Take it somewhere else. No one tried to bash you. Grow up and get over it you big baby.

    @negativeview said:

    NOBODY has defended this in as so many words.

     You have. You can't stop justifying it.

    @negativeview said:

    when I posted my first WTF (much bigger than yours, I might add)

    Again, your personal feelings towards me... christ you are pathetic.

    @negativeview said:

    Making the code only check for things once seems like an easy project to me! Charge for your time (is THAT why you're on this site constantly?) and move on with your life.

    You see, nowhere in my OP did I say I own or work on this code. That is the thing you are failing to miss in your heap of ad hominem garbage here.

     

    So, seeing as how you defended garbage code and looked like an idiot, and derailed a thread with ad hominem garbage, I wont be replying to this crap anymore. I wish I had realized where you were going with this from the beginning, because I wouldn't have answered you. I guess I gave you the benefit of the doubt that you wouldn't let your crybaby antics stand in the way of sound judgement.



  • @MasterPlanSoftware said:

    Verifying that a unique value is unique 3 times is stupid. Sorry, but you are wrong. It goes against all good logic no matter how you (lamely) try and justify it.
     

    Twice. getone() doesn't guarantee that you can't call it again, does it? I've already admitted that I don't know sqlite or python well, but the equivilant functions in C or PHP can be called multiple times. And we're dealing with a global variable.

    @MasterPlanSoftware said:

    @negativeview said:

    It's surely not worth calling anyone stupid over,

    It sure is.

    What isn't worth calling someone stupid?

     @MasterPlanSoftware said:

    Again, ad hominem attacks only pollute the forum.

    Isn't that what calling someone stupid is?

    @MasterPlanSoftware said:

    @negativeview said:

    NOBODY has defended this in as so many words.

     You have. You can't stop justifying it.

    Code does not fit into one of two categories: awesome or WTF-worthy. I have only said that the code isn't WTF-worthy. The code is nothing special. It's not without very incredibly small wtfs. I've given that code all of one compliment: it uses parameterized queries. Everything else has been me saying that yes, it has some small wtfs, but not as many and not as serious as you've made it out to be.

    @MasterPlanSoftware said:

    Ahhh, now it comes out, you are upset with my post because you don't like other posts being called out.

    I merely tire of seeing time and time again the mildly interesting posts turn into you deriding the OP for posting things that don't live up to your standards, or derailing the post because someone quoted the entire OP or quoted too much or too little, all the while claiming (falsly) to not do the same things yourself.

    I mean to provide evidence (something you haven't done when claiming that I have defended the OP code) that you are hypocritical in these arguments, saying that barely-WTF code is worthy of this site. I shouldn't have. Not because it was wrong, but because the only piece of even halfway solid ground you've found in this discussion is the desperate accusations that I'm wrong because I don't like you. I don't like you, but that doesn't necessarily make me wrong.

     



  • @MasterPlanSoftware said:

    def GetAll(id):
      """
      Returns the entire player row
      """
      global cur;
      cur.execute("SELECT * FROM player WHERE rowid = ? LIMIT 1", (id,));

      return cur.fetchone();

     

    The meat of the function looks like cut and pasted code that he just forgot to remove the limits from.  The most part I find confusing is the function name itself, GetAll seems very misleading.  I'd assume a function called GetAll would get all the Players not all the fields.  Then again, I'd have to see it in context with the rest of the functions, for all I know there's a GetName and a GetScore, etc.



  • @negativeview said:

    I've already admitted that I don't know sqlite or python well, but the equivilant functions in C or PHP can be called multiple times.
     

    Then perhaps you shouldn't post about them?

    Sorry, but I've got to agree with MPS here. The code above (even if you remove the .getone() call) is the equivalent of (since you mentioned C):

    [code]

    for (int i = 0; i < 10; i++) { // limit i to 0 through 9

      if (i >= 0 && i < 10) {  // Make sure we're between 0 and 9

        // do whatever

      }

    }

    [/code]

    I'm not sure about the need for .getone(), but if MPS is right and it isn't needed, you can add an additional "while (i >= 0 && i < 10)" between the for and the if above.

    No matter how you try and defend it, that's a WTF.

    @negativeview said:

    I merely tire of seeing time and time again the mildly interesting posts turn into you deriding the OP

    Ummm... Then don't visit this site? Don't read the comments?

    Not sure who made you defender of the weak here, but if people can't defend their own posts perhaps they should go to a different set of forums instead of expecting other people to coddle them here. Maybe then we would end up with the grownups having a professional, technical discussion instead of the script kiddies trolling their juvenile drivel and wasting our time.

    While I agree that there have been a few times I thought MPS ended up getting carried away during some comments, for the most part I have to agree; when he posts that someone is trolling or posting idiotic comments, they usually are. (Not saying I agree that you were trolling, BTW; although perhaps if you don't know about a certain technology you should either do a little research before posting a conflicting opinion, or just keep quiet. I know nothing about SQLite or Python, but can recognize from other DBMSs that ROWID is meant to represent an unique value identifying a row of data.)


     



  • @KenW said:

    I'm not sure about the need for .getone(), but if MPS is right and it isn't needed
     

    .getone() simply returns one row instead of an array of rows. It would be pointless to ask for an array of rows if you're guaranteed to only have one. I don't believe that MPS was saying that .getone() is unnecessary, just that it is guaranteed to only return one row. After all, why make yourself have to dereference the first element of the array when you'll never access any other members? If I understand the above correctly though, there's nothing keeping you from calling .getone() in a loop and getting each element that way:

    while(a = cur.getone()) {

       // do stuff

    }

    Get one doesn't imply that we can only EVER get one row from the results, it simply means "give me the next row." Correct me if I'm wrong about this particular combination of language/DB, but that's how the functions I've seen in PHP Perl and C all work.

     Your example also checks twice in the same language/domain. The original post is much more akin to using a for loop to loop over a query with a LIMIT 10 rather than a while loop, since at least in most languages/SQL libraries it simply returns NULL when there are no more rows in order to make such code easier:

    Even your example code I would roll my eyes at if I saw posted here. That would more than likely be the result of the outer loop changing scope. If I saw that in production code I'd immediately think that the outer loop used to go above 9 and 0 - 9 were special. Now the two sets of functionality are handled by different code. An inefficiency, a silly little thing, but it hardly displays a fundamental misunderstanding of the technology to forget to take out the if that is now pointless. Nor do I think that the OP code displays any fundamental misunderstanding of the technology -- it was a few extra characters with no real side-effect and still did its job in what is a reasonably close to optimal way. The function overhead and resulting lack of being able to see the exact code executing that also comes with a function call is probably worse than any side-effect of the "wtf."

    @KenW said:

    While I agree that there have been a few times I thought MPS ended up getting carried away during some comments, for the most part I have to agree; when he posts that someone is trolling or posting idiotic comments, they usually are.

     Yesterday, long after the exchange above, I went to reading "Not-so-smart Building." It went many posts talking about the subject at hand. Then morbius made a very quick one-sentence mention of dudes house being messy (it was). His post was short and to the point, even if not to the point of the actual thread, though still largely a negative shot. Enter MPS to take that to a whole new level. In a single post, we don't mention the subject of the thread: automation, especially the pointless kind. Instead we get "not fit to live in," "hopefully you were at least smart enough to..." (yay for implying stupidity in 99.9% of his posts!), calling someone a troll (in that case I may agree with him, though), and "death trap wasteland." The OP replies once, then MPS posts another negative post and the thread is dead.

    This happens to virtually all of the posts that I read. MPS is on almost every one of them, and his posts are always so overwhelmingly negative to kill the thread. The sad part is that I don't believe that he realizes how overwhelmingly negative he is. I think that he must think that he's normal, spewing vitrol in every aspect of his life.

    @KenW said:

    Ummm... Then don't visit this site? Don't read the comments?

     I may, and others may as well. But I'm not at the moment for the same reason why you don't let blatant trolls have free run of your forum or allow spam to accumulate. I truly believe that MPS is chasing away many innocent new people, and probably driving off even non-new people. Perhaps I'm the only one bothered by MPS's rampant thread-killing. And if so this thread will fade away and that'll be the end of it. I just wanted to see what would happen if someone stood up to MPS and said more than super-blatant trolling hatred of MPS like soviut's post before it was deleted. He gets a lot of that, but their blatantness and purposelessness almost makes me side with MPS when they start coming out of the woodwork.



  •  I don't really know Python, but I searched around a bit and (as other posters may have indicated), .fetchone() indeed returns a single row, while other methodes (fetchmany() and fetchall()) return a list of rows (no matter how many results there are). So actually, fetchone() makes a whole lot of sense, doesn't it? I mean, "return cur.fetchall()[0]" (or whatever the Python way of writing that is, I mean: the first element of the list returned by fetchall()) would be more "wtf". Granted, a LIMIT 1 clause isn't necessary, but it's not *that* bad is it?



  • @jensdt said:

    Granted, a LIMIT 1 clause isn't necessary, but it's not *that* bad is it?
     

    The unique key guarantees one row. The LIMIT 1 guarantees one row. Fetchone() guarantees one row. 

    Yes it is that bad.



  • @MasterPlanSoftware said:

    @jensdt said:

    Granted, a LIMIT 1 clause isn't necessary, but it's not *that* bad is it?
     

    The unique key guarantees one row. The LIMIT 1 guarantees one row. Fetchone() guarantees one row. 

    Yes it is that bad.

     

     Only the "LIMIT 1" is redundant. As I said in my last post, using anything but fetchone would be a WTF, unless there is another Python method of course. In that case feel free to enlighten me. And unless SQLite does some very strange things, the LIMIT 1 shouldn't have any impact on performance. It doesn't make the code less readable. 7 redundant characters that do not influence performance and readability. Why is it that bad?



  • @jensdt said:

    Why is it that bad?
    It's the thought process (or lack thereof) behind it that's bad. The fact that the developer clearly doesn't understand the rowid is troubling.



  • @bstorer said:

    @jensdt said:
    Why is it that bad?
    It's the thought process (or lack thereof) behind it that's bad. The fact that the developer clearly doesn't understand the rowid is troubling.
     

    I'm not sure you may say that. A quick search on Google Code revealed this type of behaviour many times (just to give one example: http://code.google.com/support/bin/answer.py?answer=80200&topic=11364). And no, "because everyone does it" isn't a good reason but I seriously doubt all those developers don't understand the concept of a unique attribute.

    IMHO this is only half of a WTF...



  • @jensdt said:

    I seriously doubt all those developers don't understand the concept of a unique attribute.
     

    Why would you doubt it? They obviously don't understand the idea. There is just no debating that.

    @jensdt said:

    IMHO this is only half of a WTF...

    Well, I did preface my OP by stating it was a small WTF. Not sure why you can't grasp the concepts here.



  • @jensdt said:

    I'm not sure you may say that. A quick search on Google Code revealed this type of behaviour many times (just to give one example: http://code.google.com/support/bin/answer.py?answer=80200&topic=11364). And no, "because everyone does it" isn't a good reason but I seriously doubt all those developers don't understand the concept of a unique attribute.
    Wow, that's who you're hitching your wagon to, huh? A guy who writes code like this:
    @http://code.google.com/support/bin/answer.py?answer=80200&topic=11364#samplecode said:
    // Select all the rows in the markers table
    $query = "SELECT * FROM markers WHERE 1";
    Good luck with that...



  • @bstorer said:

    @http://code.google.com/support/bin/answer.py?answer=80200&topic=11364#samplecode said:

    // Select all the rows in the markers table
    $query = "SELECT * FROM markers WHERE 1";

    Good luck with that...
     

    But it works as expected!



  • @bstorer said:

    @jensdt said:
    I'm not sure you may say that. A quick search on Google Code revealed this type of behaviour many times (just to give one example: http://code.google.com/support/bin/answer.py?answer=80200&topic=11364). And no, "because everyone does it" isn't a good reason but I seriously doubt all those developers don't understand the concept of a unique attribute.
    Wow, that's who you're hitching your wagon to, huh? A guy who writes code like this: @http://code.google.com/support/bin/answer.py?answer=80200&topic=11364#samplecode said:

    // Select all the rows in the markers table
    $query = "SELECT * FROM markers WHERE 1";

    Good luck with that...
     

     I said: "just to give *one* example". Breaking down this one example doesn't prove you're right.

     

    @MPS said:

    Well, I did preface my OP by stating it was a small WTF. Not sure why you can't grasp the concepts here.

    Well, my main issue was probably with your invalid criticism in the first post (I mean the one about fetchone(), which is clearly the right tool for the job here) If you take that away, al that remains is a superfluous "LIMIT 1". If the coder wouldn't grasp the simple concept of a unique identifier then surely there are worse things he/she wrote than this? If this is the worse you can come up with I assume the cause of this code isn't ignorance but something else (like copy/paste or only paying half attention when writing it or whatever).

    So IMHO, not worthy to post here...but that's my opinion. You (and everyone else) are of course fully entitled to yours, I'm not here to start a flamewar ;-)



  • @jensdt said:

    So IMHO, not worthy to post here...but that's my opinion.
     

    I have no idea what you think the sidebar is for then.

    I also doubt you understand everything wrong with the code in my OP.



  • @jensdt said:

     I said: "just to give one example". Breaking down this one example doesn't prove you're right.
    No, but it sure makes your argument look bad. Suppose I were trying to convince people that the world is flat. Would it help my argument to claim that many people believe that the world is flat, including this drunken hobo I found lying on the side of the road? Sure, you can point out that he's wearing a cardboard box as a hat and barking at fire hydrants, but that doesn't make me wrong!



  • @MasterPlanSoftware said:

    I also doubt you understand everything wrong with the code in my OP.

     

    Well, your main point is the uniqueness-issue, isn't it?

     @MPS said:


    So, we have made a query using a WHERE clause on a unique column. We have then limited the query to 1 result (???). And then on top of that, we fetchone() to make triple sure that we only return one row.

     Could you please explain the last sentence, how you know the developer uses fetchone() to *make sure* there is only one result (which, I would agree with, is a WTF) instead of *because* there is only one result (a subtle difference, but *not* a WTF).



  • @bstorer said:

    @jensdt said:
    I'm not sure you may say that. A quick search on Google Code revealed this type of behaviour many times (just to give one example: http://code.google.com/support/bin/answer.py?answer=80200&topic=11364). And no, "because everyone does it" isn't a good reason but I seriously doubt all those developers don't understand the concept of a unique attribute.
    Wow, that's who you're hitching your wagon to, huh? A guy who writes code like this: @http://code.google.com/support/bin/answer.py?answer=80200&topic=11364#samplecode said:

    // Select all the rows in the markers table
    $query = "SELECT * FROM markers WHERE 1";

    Good luck with that...
     

    Hmm. I'm okay hitching my wagon to the coding skills of a Google coder. I followed that link thinking that jensdt had picked some really crappy coding forum for backup. It's official documention written by the Google team on how to use their API. The "WHERE 1" was the biggest WTF in that snippet of code. Again, incredibly tiny. Our own DB guy here does that sometimes, and I get the impression it's an old habit from a stupider time (referring to the intelligence of the DBs in use, not the DB guy).



  • @negativeview said:

    The "WHERE 1" was the biggest WTF in that snippet of code.

    @Google Coder said:

    while ($row = @mysql_fetch_assoc($result)) {

    @Google Coder said:
    $csv = file_get_contents($request_url) or die("url not loading");

    @Google Coder said:
    $csvSplit = split(",", $csv);

    That's as far as I got before I gave up.  Oh, the code examples also use LIMIT 1 on all of the update statements, even though they are updated using the unique ID as well. 



  • i don't know enough PHP to be able to comment properly on that first one.  unless they're using the @ to cast the hash it's returning to an array?

     

    file_get_contents is a pretty stupid name, seeing as it's not limited to filesystem-based documents.   but since in this case it is being used to fetch data over the web, bailing out when it fails seems to be a perfectly reasonable response.

     

    parsing that wretched CSV format using split isn't generally a good idea, but since google themselves specify that the response won't contain any stray commas (only integers and latitude/longitude specifiers), that's not a problem.

     

    the whole thing is pretty hacky (note the typos and messed up grammar in some of the messages), but nothing particularly offensive as far as i can see.



  • @ligne said:

    i don't know enough PHP to be able to comment properly on that first one.  unless they're using the @ to cast the hash it's returning to an array?
     

    They are ignoring errors. Pretty WTF-ey to me.

     I am not a PHP guy either, but I was able to use Google.



  • @ligne said:

    i don't know enough PHP to be able to comment properly on that first one.

    You obviously don't know PHP well enough to comment on any of them so why are you bothering?



  • @ligne said:

    parsing that wretched CSV format using split isn't generally a good idea, but since google themselves specify that the response won't contain any stray commas (only integers and latitude/longitude specifiers), that's not a problem.
    You fool! You can't just rely on them to tell you it won't have any stray commas! Hasn't this thread taught you anything? You have to expect all programs you interact with to fail in impossible ways.



  • @bstorer said:

    but since google themselves specify that the response won't contain any stray commas
     

     

    What if you get a partial response ?  No matter who it is, you almost never trust input from external sources without validating it. Suppose google decides to make a change 2 years from now ?   Is your program going to break then ? 



  • @pitchingchris said:

    @bstorer said:
    but since google themselves specify that the response won't contain any stray commas
     
     

    You completely fail at quoting.



  • @pitchingchris said:

    Suppose google decides to make a change 2 years from now ?   Is your program going to break then ? 

     

     indeed.  though i think that as and when they do that, they might update their code samples to match.  and perhaps more importantly, if they modify the first four fields to contain commas, you're almost certainly going to have to rewrite your code anyway.

     

     



  • sorry for misquoting you bstorer, I pulled it out of your quote of ligne. I kinda expected the person to jump on me for it would be MPS.



  • @pitchingchris said:

    I kinda expected the person to jump on me for it would be MPS.
     

    So you did it on purpose then?



  • @MasterPlanSoftware said:

    So you did it on purpose then?

    All I'm saying is that of all people that could have called me out on a mistake, I knew it would be you.



  • @pitchingchris said:

    All I'm saying is that of all people that could have called me out on a mistake, I knew it would be you.
     

    How does that have any relevance to anything though?


Log in to reply