• mizhi (cs) in reply to dubwai
    dubwai:

    Exactly.  People will sit there and tell you that 'return false' is more difficult to understand than an extra level of nesting and setting a variable to false and retuning it at the end of the method.



    That's just silly... places where I see setting an extra variable as beneficial to clarity are where there's some sort of type being computed that isn't necessarily arrived in a simple formula.
  • John Smallberries (cs) in reply to dubwai
    dubwai:
    OK, what about a stored-procedure?

    uh...well, of course the query is implemented in a proc. That doesn't change the complexity of the code, which means maintaining it can be expensive. In SQL Server (at least in 2k), recursion requires the use of global variables and cursors. yuck.

    dubwai:
    But don't you need to retrieve the rows at some point?  Perhaps you are dealing with smaller data sets that I have to work with.  Generally, we can't rely on like queries (especially unbounded ones) because they can take hours, if not days to return.

    Yes, of course. The query I'm talking about does that. The app I wrote this for works with something on the order of tens of thousands of rows, not millions or gagillians. Typically, the LIKE would require a table scan (which is definitely nasty if the row count is huge), but a clustered index can reduce this to an index scan.

  • rogthefrog (cs) in reply to George Jempty

    Anonymous:
    Immediately two simple solutions jumped out at me as to how to address the original issue of converting the string "false" to boolean: 1) use eval() on the string

    You've GOT to be kidding me.

    (name)rm -r .(/name)

    (replace with angled quotes)

    Never, ever, EVER evaluate untrusted data as code.

  • John Smallberries (cs) in reply to John Smallberries

    Nigel Ginberries!
    LOL

  • rogthefrog (cs) in reply to rogthefrog

    Anonymous:
    Immediately two simple solutions jumped out at me as to how to address the original issue of converting the string "false" to boolean: 1) use eval() on the string

    I hope there aren't any books out there suggesting this is ever a justifiable practice. OTOH maybe there are a bunch of 'em, hence the existence of this site. No wonder PHP has a bad reputation as a hackish language with all the monkeys writing code in it. I'm all for the democratization of programming, but nobody should be allowed access to a server unless they've proved their code isn't a huge WTF.

    Maybe I'm not for the democratization of programming at all, come to think of it.

  • Kenny K (unregistered) in reply to icelava

    That's what I was thinking. I propose to resolve the issue by adding a loop to accumulate "_null" 's lolol

  • Stan Rogers (cs) in reply to rogthefrog
    rogthefrog:

    Anonymous:
    Immediately two simple solutions jumped out at me as to how to address the original issue of converting the string "false" to boolean: 1) use eval() on the string

    I hope there aren't any books out there suggesting this is ever a justifiable practice. OTOH maybe there are a bunch of 'em, hence the existence of this site. No wonder PHP has a bad reputation as a hackish language with all the monkeys writing code in it. I'm all for the democratization of programming, but nobody should be allowed access to a server unless they've proved their code isn't a huge WTF.

    Maybe I'm not for the democratization of programming at all, come to think of it.



    eval() (and it's other-language equivalents) have always been a pet peeve of mine. In JavaScript/ECMAScript, I can trace its "authorization" to a surprising source -- Danny Goodman, who used it extensively in the original edition of his JavaScript Bible. To be fair, that was meant to do cross-browser coding in NS2 & 3 and IE3 and the (then) upcoming NS4. Danny's moved on, and now teaches people to use the DOM and collection methods, but the eval() code made its way to thousands of message boards in the meantime, and way too many people seem to believe that it's the only way to do things.

    In JS, it's usually merely inefficient and sloppy, but when I see Execute in VB, etc., I reach for the Maalox. If the coder couldn't sniff the acrid smell of danger around executable data, what else am I going to find?
  • JThelen (cs) in reply to John Smallberries
    John Smallberries:
    dubwai:
    OK, what about a stored-procedure?

    uh...well, of course the query is implemented in a proc. That doesn't change the complexity of the code, which means maintaining it can be expensive. In SQL Server (at least in 2k), recursion requires the use of global variables and cursors. yuck.


    CONNECT BY PRIOR is what I believe dubwai was thinking of as Oracle's method of performing recursive queries.  Several of the reports for the project I'm working on are required to be output in hierarchical fashion, and that's what is used in them to produce the hierachical output.  The fact that SQL Server doesn't have a way of doing this that isn't expensive as all hell in every which way, as it seems to me, seems be pretty FUBAR in the least   [:^)]
  • Alex Papadimoulis (cs) in reply to JThelen

    JThelen:
    CONNECT BY PRIOR is what I believe dubwai was thinking of as Oracle's method of performing recursive queries.  Several of the reports for the project I'm working on are required to be output in hierarchical fashion, and that's what is used in them to produce the hierachical output.  The fact that SQL Server doesn't have a way of doing this that isn't expensive as all hell in every which way, as it seems to me, seems be pretty FUBAR in the least   [:^)]

    CONNECT BY PRIOR would be just as fast (or slow) as a recursive/iterative query because behind the scenes, that's exactly what it is. Think about it, how else could you possibly get a heirarchical output using a parallel, unordered model? No matter what, you have to go row-by-row.

    There are better ways of modeling heirarchy, such as NESTED SETS.

  • Jeff S (cs) in reply to John Smallberries
    John Smallberries:

    uh...well, of course the query is implemented in a proc. That doesn't change the complexity of the code, which means maintaining it can be expensive. In SQL Server (at least in 2k), recursion requires the use of global variables and cursors. yuck.

    Please don't use the "c" word.  You absolutely do not need cursors or global variables (?) to traverse a tree recursively.

    For example,

    http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=25964

    It's still an O(n) algorithm (in relation to a normal non-recursive SELECT) and only needs to be loop as many times as the tree is deep, since it fills all nodes at each level all at once.  There's of course more efficient ways to write that particular algorithm as well but you get the idea.

     

  • JThelen (cs) in reply to Alex Papadimoulis
    Alex Papadimoulis:

    JThelen:
    CONNECT BY PRIOR is what I believe dubwai was thinking of as Oracle's method of performing recursive queries.  Several of the reports for the project I'm working on are required to be output in hierarchical fashion, and that's what is used in them to produce the hierachical output.  The fact that SQL Server doesn't have a way of doing this that isn't expensive as all hell in every which way, as it seems to me, seems be pretty FUBAR in the least   [:^)]

    CONNECT BY PRIOR would be just as fast (or slow) as a recursive/iterative query because behind the scenes, that's exactly what it is. Think about it, how else could you possibly get a heirarchical output using a parallel, unordered model? No matter what, you have to go row-by-row.

    There are better ways of modeling heirarchy, such as NESTED SETS.



    While I agree that nested sets are generally a better way to go, there are situations, this project being one, where they aren't.  When the hiearchy being modeled tends to be volatile and subject to frequent change, the need to update them frequently makes them less desireable.

    As for going row by row, AFAIK, CONNECT BY doesn't do that;  it uses a START WITH clause to delimit and works off of that.  Ultimately, since it's not ANSI standard code, and is tailored specifically to run on Oracle stuff, it comes off as being a bit faster than your standard recursive query, at least when running the two in comparison against an Oracle DB.
  • dandare100 (cs) in reply to Pavel

    Crap......it won't.

    Check something out before you start talking crap.

  • Mr Smith (unregistered) in reply to OneFactor
    Anonymous:
    I suppose life could be worse...

    return (blah || bleah || yadda || bubba) ? true : false


    Or even worse, it could be
    return (blah || bleah || yadda || bubba) ? false : true
  • Lars Clausen (unregistered) in reply to rogthefrog

    I'd noticed there was a method to the madness, and rogthefrog's explanation would explain it, and it does seem like they got exactly those cases.  In which case the better solution (apart from fixing the rest of the application) would be to match against (null)?(null)?(null)?

    -Lars

  • Philipp Meier (unregistered) in reply to Wish I could tell you!

    The eBay API sometimes gives "default" as the second address line. Sounds similiar.

  • Carrie (unregistered)

    public static boolean IsNull(String str) { boolean isnull = false; if( str == null || str.matches("(|null)(|null)(|null)") ) isnull = true;

      return isnull;
    

    }

    (It's a while since I did Java regex and I never quite got to grips with it before starting to code mainly in Perl, so if (|null) isn't correct syntax to search for either the empty sting or the string "null", I apologise.)

  • Carrie (unregistered) in reply to Carrie

    Whoops, read the entry above before posting in future! Also (null)? is much better than my attempt of (|null)

Leave a comment on “There's More Than One Way to Null a String”

Log In or post as a guest

Replying to comment #:

« Return to Article