• (cs)

    I saw something similar to this in a customers code that was done intentionally. They were afraid a critical call would error out, so executed it 3 times in 10 minutes (Starting at 1AM) just incase. Unfortunately the call invoked a process that took 4.5 hours to complete, and they had 'assumed' that if it completed the first time that the system was smart enough not to execute the second and third instances without any instructions or error handling.......The only reason I was brough in was because the server was locked up every morning when they came in as the instances ran serially....DOH! [8-|]

  • (cs) in reply to trollable

    And even worse that they then edit generated code.  This way lies misery....

  • (cs)

    As far as I can tell, FieldMap.Organization, FieldMap.Tag and FieldMap.Slate are all enumerations which contain the mapping of column "names" to indices. Thus "dr[FieldMap.Tag.is_active]" is getting the "is_active" field from a DataRow, which has been populated from the Tag table.

    The cast to bool can be explained too. This definitely looks like C#, in which case the operator [int] returns the value of the specified column. It's most likely a bit field (SQL Server) or a yes/no field (Access MDB). As the value's returned as an object, the cast to bool would be valid.

    But yes, the WTF here is the triple check. It obviously won't avoid any kind of race condition, because:
    (1) The data can still change between the last check and when addBlahRow() is called.
    (2) The data is almost certainly cached client-side, making each check return the same value.
    (3) The compiler/linker might optimize it all down to 1 check anyway.

  • Guest (unregistered) in reply to t-bone
    t-bone:
    paid by the line anyone?
    even if he wanted to do this, he could 've refactored it to a function tripleCheck()


    Ah, but if he was going to refactor the chek out to a function then surely you want to be certain...

    function makeAbsolutelySure(bool test) {
        return makeAbsolutelySure(test)
    }

    foreach(DataRow dr in organizations)
    {
    if (makeAbsolutelyCertain((bool)dr[FieldMap.Organization.is_active])
    addOrgRow(dr);
    }
    }

  • (cs) in reply to Viewer

    Anonymous:
    Irrelevant:
    Looks to me like this could be protection from race conditions by someone who doesn't really grep threaded programming.

    Looks to me like this could be written by someone who doesn't really grok the difference between "grep" and "grok".

    Yeah.

    Bad geek! Bad, BAD geek!! No pizza!!

  • Sheldon (unregistered)

    This is a good example of test-driven development.

    :)

  • (cs)

    Irish?

  • Anonymous (unregistered) in reply to eimaj2nz

    eimaj2nz:
    As far as I can tell, FieldMap.Organization, FieldMap.Tag and FieldMap.Slate are all enumerations which contain the mapping of column "names" to indices. Thus "dr[FieldMap.Tag.is_active]" is getting the "is_active" field from a DataRow, which has been populated from the Tag table.

    The cast to bool can be explained too. This definitely looks like C#, in which case the operator [int] returns the value of the specified column. It's most likely a bit field (SQL Server) or a yes/no field (Access MDB). As the value's returned as an object, the cast to bool would be valid.

    But yes, the WTF here is the triple check. It obviously won't avoid any kind of race condition, because:
    (1) The data can still change between the last check and when addBlahRow() is called.
    (2) The data is almost certainly cached client-side, making each check return the same value.
    (3) The compiler/linker might optimize it all down to 1 check anyway.

    First of all, this does appear to be C#; not because of the syntax itself, but that it is also using a DataRow which is one of the ADO.NET classes.

    "FieldMap.Organization.is_active" is either a static or a const 'int' or 'string' value; it cannot be discerned which since the indexer (or 'Item' property) for the DataRow is overloaded.  It cannot, however, be an enumeration in C#, because enumerated values are not implicitly 'int' types and would have required an explicit cast to an 'int' in order to compile.  (Of course, I'm making the assumption that this code snippet did compile without error.)

    Because the indexer for DataRow returns an 'object', it is either a reference to some other class type or a boxed value type (which is the data contained in the referenced column for that row) and would be required an explicit cast to unbox the 'bool' in order to use it in a logical expression (i.e. the 'if' statement).  The "is_active" somewhat reinforces that the referenced column in that data row may very well contain boolean data.

    "organizations", "tags", et al. are DataRowCollection objects which are most likely assigned from the 'Rows' property for the given table they are iterating through to examine.

    This could possibly be the result of code that was spit out by some type of code generator; perhaps the original author tested the generated code, found that it worked and the resulting code that was generated henceforth was never questioned by anyone that used it -- out of sight, out of mind.  That is, of course, until a new developer comes along that needs to either make changes to the generator or examines the generated code to determine how things work.

  • David (unregistered) in reply to Broonix

    "its always a good idea to check everythign a few times before you process any data.... *gag*"

     

    Ah, like you checked your spelling! [:P]

  • (cs) in reply to Tack
    Anonymous:
    The only thing I can think of is that there were concurrency issues, and the original coder thought this would be a workable solution.  After all, if the value remains unchanged after three whole tests, surely any possible race conditions have been thwarted!

    Jason.


    What database could give different results for the first, second and/or third call of is_active, even considering concurrency and stuff?
  • Submitter (unregistered)

    To debunk all the theories.....

    1. It's C#.  dr[FieldMap.Tag.is_active] returns what value was in the is_active column of the Tag table as an object, hence the cast to a bool.

    2) It wasn't generated by a code-generator, it was hand written.

    3) I wasn't drunk when i was first reading the code.  I wanted to get drunk immediately afterward, but lunch wasn't for another hour.

    4) The explanation i received was that the value in the DB might have changed after the first if statement so they checked it again... twice.  Why only twice? I don't remember if i asked that or not.  The funny part about this is the values are already pulled from the db and are in the DataRow, and will not change unless the DataRow is repopulated, so there is absolutely no reason to check it three times.

    I believe it was due to copy/paste, but will probably never know.

    Of course, this code is from the same guy who chose to implement the entire project without using form designer because he believed the .res files that the form designer generated created too much overhead.  This was the main reason for the file being 28,600 lines (yes, exactly 28,600.)
  • dave (unregistered) in reply to DevNull

    RE: the Lewis Carrol school of programming.

    You, Sir, are one of the rare programmers educated in programming history.

    I believe the Bellman was modelled on Charles Babbage, so the triple-if is clearly the only way to evaluate boolean propositions.


  • (cs) in reply to TankerJoe
    TankerJoe:
    pfft.  The real wtf is the complete lack of error handling:

    <FONT size=3>bool unthinkableMayhem = invert_bool(true);
    </FONT>
    <FONT size=3>foreach(DataRow dr in organizations){ 
    if ((bool)dr[FieldMap.Organization.is_active]){
    if ((bool)dr[FieldMap.Organization.is_active]){
    if ((bool)dr[FieldMap.Organization.is_active]){
    addOrgRow(dr);
    }else{
    unthinkableMayhem = invert_bool(false);
     }
    }else{
    unthinkableMayhem = invert_bool(0);
    }
    }else{
    unthinkableMayhem = invert_bool(-0);
    }
    }
    if (invert_bool(unthinkableMayhem)){
    return "Brillant";
    }else{
    return "FileNotFound";
    }
    return;</FONT>



    Almost, but you forgot the mandatory IsTrue() call.

      if (IsTrue((bool)dr[FieldMap.Organization.is_active])){
        if (IsTrue((bool)dr[FieldMap.Organization.is_active])){
          if (IsTrue((bool)dr[FieldMap.Organization.is_active])){...

    ;)

  • DrDoom (unregistered) in reply to Mark
    Anonymous:

    Question: Wouldn't whichever compiler/interpreter this was written for not optimise and remove the duplicate tests? That would mean it doesn't even work in the 'avoid race conditions' explanation.

     

    No it would not, or at least I hope not. The compiler looks at code and checks it for logical/structural errors( if command without then) and internal reserved words/commands (do = do +1).

    <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p> </o:p>

    The reason why I think this was done is to avoid the ‘wait (X)’ seconds command to see if the changes occurred. Why would he avoide it? I don’t know.

     

  • Runtime Error (unregistered) in reply to null

    Well I heard that if you stand in front of a mirror and refererence FieldMap.Organization.is_active three times in a row that it comes alive and kills you.

  • DrDoom (unregistered) in reply to hahanoob

    Anonymous:
    Gene Wirchenko:
    Anonymous:
    The only thing I can think of is that there were concurrency issues, and the original coder thought this would be a workable solution.  After all, if the value remains unchanged after three whole tests, surely any possible race conditions have been thwarted!


    I agree about concurrency.

    It depends on the compiler, but the extra checks might well be optimised away.

    Sincerely,

    Gene Wirchenko



    What the hell is wrong with you? Stop signing your posts.

    hahanoob

    Actually he is in compliance with the law and we are not.

    <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p> </o:p>

    It is now illegal for US citizens to annoy people without providing your true identity.

    <o:p> </o:p>

    Read this article: on theinquirer.net. Unfortunately it is not a joke but is truly WTF!

    http://www.theinquirer.net/?article=28971

     

  • Co-worker of Sam Snee (unregistered)

    hahahaha, this code is posted up right outside my cube.... I have written across the paper, "WTF?" in nice software dev. chicken scratch.

    a nice copy n paste technique by one of our collegues (actually, a really smart guy, although I still can't figure out why he tried to justify it to me). The biggest WTF is 28,600 lines long tho, and trust me, the repeated if-statements are just the tip of the iceberg.

    When ppl are under pressure, when specs are changed after development is done, hell, when there are no specs and a looming deadline sits in front of a hobbled project, ppl will do whatever it takes to spit it out as fast as possible, which usually is (as you can tell) a BAD idea, but one not necessariliy brought upon the project by the dev team. You know what really cracks me up about the previous project was the old management. We had another guy who was contracting for us, good friend and really smart guy BTW (he works on 3D modeling systems now), but didn't know diddly about SQL, and was pretty much asked to finish our whole reporting system single-handedly.

    The result for one of our reports was a 36,000 line sproc. I'd love to share it sometime. :D

    Sometimes the real WTF is why nobody was listening on either side of the fence when something sounded horribly wrong. The real WTF was a breakdown of the communication lines, and a breakdown of good management, and finally, a breakdown of the dev. team.

    It's nice to still work for this company, because they have really turned around. Code separation is nice, and there no longer will be 10,000 (10,000!) lines of migration code in the interface layer because we have a boss that truly believes in practicing outstanding OO development OF a layered architecture, someone with 15 years of experience who will make sure he doesn't see the crap hit the code.



    PS: no auto-generating. but trust me, we are laughing/crying with you and are just as mind-boggled as well, I'm sure. DataRows are in C#, pulled from DataTables, DataSets, etc etc etc (I suggest DataReaders for speedy access). They get tied into the Business Objects in a pretty funky way, if you are really that curious... here is a note from the  previous developer (DB specialist), who, I might add once again, was a very smart guy, and really knew his stuff (DB expert). It's just that when smart ppl are under pressure without a strong leader at the helm... you get this lurking deep in the base class for the business logic.

                    //TODO explain this monstrosity better
                    return (DataRow) DbGateway[(int)((ArrayList)DbGateway.KeyIds[baseTable])[index], key_Name];

    Unfortunately, no better explanation was left. And this was true for most of the code, for anyone, anywhere. OO concepts were used, sometimes a few comments were injected in to the spaghetti, and some developers who left the company were kind enough to try to make some sense of the mayhem for the newcomers and let them know the kind of fallouts they experienced. Sometimes you make due with what you got, be glad your company stood by you through it after telling them not to continue the project because it was a POS (P := 'pile'), and be very happy that they made the right decisions to dump the project and to get highly qualified people to lead the team with a passion and a desire to work on something that should be more like a Piece Of Art than a POS.

  • Co-worker of Sam Snee (unregistered) in reply to Co-worker of Sam Snee

    My bad, I forgot to put quotes around the word "used" when talking about OO concepts. :D

  • (cs) in reply to DrDoom
    Anonymous:
    Anonymous:
    Question: Wouldn't whichever compiler/interpreter this was written for not optimise and remove the duplicate tests? That would mean it doesn't even work in the 'avoid race conditions' explanation.

    No it would not, or at least I hope not. The compiler looks at code and checks it for logical/structural errors( if command without then) and internal reserved words/commands (do = do +1).
    <o:p>

    </o:p>

    <o:p>The language need not have reserved words.  FORTRAN is an example of this.  I believe PL/I also is.
    </o:p>

    <o:p>A compiler can do far more than that limited checking.  How much it can get away with depends on the language.
    </o:p>

    Sincerely,

    Gene Wirchenko

  • (cs)

    A good example of get-tough data interrogation techniques. Obviously the data is reluctant and will only participate when pushed.

  • Cap'n Gown (unregistered)

    He's de-bouncing the keyboard or something similar...

  • LoL (unregistered) in reply to Cap'n Gown

    Hes taking into account an unfair bias on the True condition

  • (cs) in reply to Anonymous
    Anonymous:

    It cannot, however, be an enumeration in C#, because enumerated values are not implicitly 'int' types and would have required an explicit cast to an 'int' in order to compile.  (Of course, I'm making the assumption that this code snippet did compile without error.)



    Please see the following snippet from the MSDN documentation on enumerations in .NET:


    An enumeration (enum) is a special form of value type, which inherits from <MSHelp:link tabindex="0" keywords="frlrfSystemEnumClassTopic">System.Enum</MSHelp:link> and supplies alternate names for the values of an underlying primitive type. An enumeration type has a name, an underlying type, and a set of fields. The underlying type must be one of the built-in signed or unsigned integer types (such as Byte, Int32, or UInt64). The fields are static literal fields, each of which represents a constant.


    Unless I'm reading this wrong, it's quite possible for an enumerated value to be implicitly cast to an integer (assuming that the underlying type is an integer or smaller). It's definitely true though that you cannot convert the other way (integer -> enum value) without a typecast.
  • (cs) in reply to LoL

    Anonymous:
    Hes taking into account an unfair bias on the True condition

    Very interesting.  I didn't notice it before - but you bring it to light. The side effect of the routine... is the added overhead when the first test resolves TRUE. The delay behavior is amplified based on the probability of TRUE in the data.

  • Nello? (unregistered) in reply to akrotkov

    It's not an array - it's a DataRow.  FieldMap.Organization.is_active is most likely a const string identifying the column name (prolly "IsActive").  Since this call to dr[] returns an object, it has to be cast to a bool to be of any use... Essentially this code is like saying: "if the organization is active, add the row dr..." 

    (God I need to leave work!).

  • (cs) in reply to Nello?

    Even scarier: What is the .is_active actually isn't a property but a method? What if is actually does something and maybe needs to be executed a few times before it returns true? Or what if it handles errors with a messagebox and gives the users 3 tries when failing?

    *shiver*

  • (cdep) illabout (unregistered) in reply to TankerJoe
    TankerJoe:
    pfft.  The real wtf is the complete lack of error handling:

    <font size="3">bool unthinkableMayhem = invert_bool(true);
    </font>
    <font size="3">foreach(DataRow dr in organizations){ 
    if ((bool)dr[FieldMap.Organization.is_active]){
    if ((bool)dr[FieldMap.Organization.is_active]){
    if ((bool)dr[FieldMap.Organization.is_active]){
    addOrgRow(dr);
    }else{
    unthinkableMayhem = invert_bool(false);
     }
    }else{
    unthinkableMayhem = invert_bool(0);
    }
    }else{
    unthinkableMayhem = invert_bool(-0);
    }
    }
    if (invert_bool(unthinkableMayhem)){
    return "Brillant";
    }else{
    return "FileNotFound";
    }
    return;</font>





    I was not aware that anyone had this level of brillance!
  • (cs) in reply to (cdep) illabout
    Anonymous:
    TankerJoe:
    pfft.  The real wtf is the complete lack of error handling:

    <FONT size=3>bool unthinkableMayhem = invert_bool(true);
    </FONT>
    <FONT size=3>foreach(DataRow dr in organizations){ 
    if ((bool)dr[FieldMap.Organization.is_active]){
    if ((bool)dr[FieldMap.Organization.is_active]){
    if ((bool)dr[FieldMap.Organization.is_active]){
    addOrgRow(dr);
    }else{
    unthinkableMayhem = invert_bool(false);
     }
    }else{
    unthinkableMayhem = invert_bool(0);
    }
    }else{
    unthinkableMayhem = invert_bool(-0);
    }
    }
    if (invert_bool(unthinkableMayhem)){
    return "Brillant";
    }else{
    return "FileNotFound";
    }
    return;</FONT>





    I was not aware that anyone had this level of brillance!

    This is the PERFECT algorithm for politics.  Ask the same question three times, or offer three similar soultions. You could run for office with this logic.

  • Bingo (unregistered) in reply to YouDidn'tSeeAnything
    Anonymous:
    So WTF did he replace it with?  It'd be much better to scoff at the existing code if it was successfully replaced with something better.  Otherwise, the WTF'er is still clueless as to WTF the problem is that caused the original coder to do three checks in the first place.




    Bingo
  • Bingo (unregistered) in reply to Viewer
    Anonymous:
    Irrelevant:
    Looks to me like this could be protection from race conditions by someone who doesn't really grep threaded programming.

    Looks to me like this could be written by someone who doesn't really grok the difference between "grep" and "grok".


    Good for you, Michael Smith
  • Bingo (unregistered) in reply to Bingo
    Anonymous:
    Anonymous:
    Irrelevant:
    Looks to me like this could be protection from race conditions by someone who doesn't really grep threaded programming.

    Looks to me like this could be written by someone who doesn't really grok the difference between "grep" and "grok".


    Good for you, Michael Smith


    Was that Michael Valentine Smith?
  • (cs)

    assuming we are dealing with strongly typed datasets (since there is no implementation of the IEnumerator in the generic datatable),

    the WTF is actually in the checking of the field value, albeit thrice! Even were it once, it would still constitute as a WTF. Imagine having 50,000 records with just 50 records meeting the criteria. To loop through that is unforgivable.

    The appropriate way is to first understand what ADO.NET can do for you and then use it. In this case, we use DataViews.

    <font size="2">// the view is disposed once it goes out of scope
    // we deal only with the DataRows that match the required criteria
    using (DataView view = new DataView(tags, FieldMap.Tag.is_active + " = true", string.Empty, DataViewRowState.CurrentRecords)
    {
        foreach(DataRowView rowView in view)
        {
          addTagRow(rowView.Row);
        }
    }</font>


  • GrandInquisitor (unregistered) in reply to boogieman

    My thoughts exactly, but perhaps that's because I'm related to an OCD sufferer.

  • Paula (unregistered)

    It's brillant. Wonder why I didnt think of that.

    Oh wait.... i wasn't paid by line of code. Phew.


    -Paula.

  • nick chan (unregistered)

    maybe is_active is a property that checks state of something? and the requirement is at least 3 times? not sure if property works that way in non-vb.net languages

  • nvoigt (unregistered) in reply to akrotkov
    akrotkov:
    ferrengi:
    Alex Papadimoulis:
       if ((bool)dr[FieldMap.Organization.is_active]) 
    {
    addOrgRow(dr);
    }


    I'm curious to know what the hell he is doing casting
    FieldMap.Organization.is_active

    to a bool. Isn't is_active already a bool?
    If it isn't, what does the cast accomplish anyway? Does he think that (bool)x is false when x is 0 and
    true when x is 1?

    WTF?!

    I tried really hard to come up with an explanation as to why he checked everything three times but I just can't figure it out.
    I don't buy the BS (I'm also not sure if people are kidding or not) about concurrency.
    Seriously, do you think that someone who writes code like this has heard about concurrency issues?
    It's amazing the guy has a job at all!



    He's actually casting dr[], which is another wtf, using a boolean for accessing an array.

    Where did you get that thought from ? Boolean ? We don't know the type at all. It is perfectly possible that is_active is of type System.Animals.Types.PinkElephant.

    dr is a DataRow. The indexer probably is a class full of constants, is_active is the name of their database table field, which probably contains 1 and 0 as there are some databases ( Oracle *hint* *hint* ) that don't have boolean field types. So is_active is probably an integer or string constant to connect the array to the database field. Not as bad as placing a magic "5" in there so that everyone maintaining it has nightmares.

    The triple checking really is a WTF, the rest is not.

     

    *prays that quoting will work*

  • rgesrgr (unregistered) in reply to Darax The Good
    1) It's autogen code.
    2) He's stupid.
    3) He's being paid by the line.
  • rgesrgr (unregistered) in reply to b1xml2
    b1xml2:
    assuming we are dealing with strongly typed datasets (since there is no implementation of the IEnumerator in the generic datatable),

    the WTF is actually in the checking of the field value, albeit thrice! Even were it once, it would still constitute as a WTF. Imagine having 50,000 records with just 50 records meeting the criteria. To loop through that is unforgivable.

    The appropriate way is to first understand what ADO.NET can do for you and then use it. In this case, we use DataViews.

    <FONT size=2>// the view is disposed once it goes out of scope
    // we deal only with the DataRows that match the required criteria
    using (DataView view = new DataView(tags, FieldMap.Tag.is_active + " = true", string.Empty, DataViewRowState.CurrentRecords)
    {
        foreach(DataRowView rowView in view)
        {
          addTagRow(rowView.Row);
        }
    }</FONT>


    And what do you think ADO.NET is doing when it creates that DataView?  Hint: It ain't gonna be any faster that looping yourself.
  • GmH (unregistered) in reply to Omnifarious

    I used to work with a programmer who routinely did something very similar.  His while loops were always of the form

    while(condition) {

           if(condition) {

                ...

           }

    }

    in single-threaded code too, so no concurrency issues.   His reason?   "Just in case." 

  • SirMixALot (unregistered) in reply to TankerJoe
    TankerJoe:

    I = BigButts.like() && I.lie(false);


    Ha, ha. Great fun :)

  • me (unregistered) in reply to Gene Wirchenko

    perhaps some "lock" may be usefull if this is done for concurrency.
    anyway, if the value remains unchanged, no need to be thread safe

  • Anonumouse (unregistered)

    Irish coder! To be sure, to be sure, to be sure.

  • Dave (unregistered)

    Is it possible that the DataRow dr contains 3 columns and that each FieldMap.Slate, etc is returning the current Slate before iterating to the next? He's therefore checking each Slate in the DataRow before adding it. But yeah, that's still pretty WTF'ed up.

  • Anonymous (unregistered) in reply to eimaj2nz
    eimaj2nz:
    Anonymous:

    It cannot, however, be an enumeration in C#, because enumerated values are not implicitly 'int' types and would have required an explicit cast to an 'int' in order to compile.  (Of course, I'm making the assumption that this code snippet did compile without error.)



    Please see the following snippet from the MSDN documentation on enumerations in .NET:


    An enumeration (enum) is a special form of value type, which inherits from <?XML:NAMESPACE PREFIX = MSHelp /><MSHelp:link tabIndex=0 keywords="frlrfSystemEnumClassTopic">System.Enum</MSHelp:link> and supplies alternate names for the values of an underlying primitive type. An enumeration type has a name, an underlying type, and a set of fields. The underlying type must be one of the built-in signed or unsigned integer types (such as Byte, Int32, or UInt64). The fields are static literal fields, each of which represents a constant.

    Unless I'm reading this wrong, it's quite possible for an enumerated value to be implicitly cast to an integer (assuming that the underlying type is an integer or smaller). It's definitely true though that you cannot convert the other way (integer -> enum value) without a typecast.

    You are not reading it wrong, you are just interpreting it wrong.  The C# language, while it can create enumerations of different underlying types (of integral values, specifically), does not implicitly cast enumeration values to that underlying type when assigning or passing as parameters.  From the MSDN documentation on C# enumerations:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/html/vcrefTheEnumerationTypes.asp

    Note the section under 'Remarks' which reads: "The underlying type specifies how much storage is allocated for each enumerator. However, an explicit cast is needed to convert from enum type to an integral type."

  • (cs) in reply to Bingo
    Anonymous:
    Anonymous:
    Anonymous:
    Irrelevant:
    Looks to me like this could be protection from race conditions by someone who doesn't really grep threaded programming.

    Looks to me like this could be written by someone who doesn't really grok the difference between "grep" and "grok".


    Good for you, Michael Smith


    Was that Michael Valentine Smith?


    It would have to be...

    But isn't it interesting that we have a Heinlein side-note in a thread all about the notion that 'I tell you 3 times it's true' - a notion that Heinlein himself was quite inordinately fond of?


    The world is truly a coincidental place - or is it?
    Maybe it's all run by infinite groups of non-real alien beings :)
  • hypernewbie (unregistered)

    good security, check three times just in case theres a virus modifying random bits of memory

  • (cs) in reply to rgesrgr

    Therein lies the difference between an ignoramus like your good self and those that take some time to look under the hood. It is faster to use a DataView then to do the loop.

    Anonymous:
    b1xml2:
    assuming we are dealing with strongly typed datasets (since there is no implementation of the IEnumerator in the generic datatable),

    the WTF is actually in the checking of the field value, albeit thrice! Even were it once, it would still constitute as a WTF. Imagine having 50,000 records with just 50 records meeting the criteria. To loop through that is unforgivable.

    The appropriate way is to first understand what ADO.NET can do for you and then use it. In this case, we use DataViews.

    <font size="2">// the view is disposed once it goes out of scope
    // we deal only with the DataRows that match the required criteria
    using (DataView view = new DataView(tags, FieldMap.Tag.is_active + " = true", string.Empty, DataViewRowState.CurrentRecords)
    {
        foreach(DataRowView rowView in view)
        {
          addTagRow(rowView.Row);
        }
    }</font>


    And what do you think ADO.NET is doing when it creates that DataView?  Hint: It ain't gonna be any faster that looping yourself.

  • jrenaut (unregistered) in reply to eimaj2nz
    eimaj2nz:
    As far as I can tell, FieldMap.Organization, FieldMap.Tag and FieldMap.Slate are all enumerations which contain the mapping of column "names" to indices. Thus "dr[FieldMap.Tag.is_active]" is getting the "is_active" field from a DataRow, which has been populated from the Tag table.

    The cast to bool can be explained too. This definitely looks like C#, in which case the operator [int] returns the value of the specified column. It's most likely a bit field (SQL Server) or a yes/no field (Access MDB). As the value's returned as an object, the cast to bool would be valid.

    But yes, the WTF here is the triple check. It obviously won't avoid any kind of race condition, because:
    (1) The data can still change between the last check and when addBlahRow() is called.
    (2) The data is almost certainly cached client-side, making each check return the same value.
    (3) The compiler/linker might optimize it all down to 1 check anyway.


    My thoughts exactly.

    Cheers.
  • jmo (unregistered) in reply to Darax The Good

    Darax The Good:
    What if the == operator was overloaded to have side effects?

    it doesnt use the == operator though!

  • jmo (unregistered) in reply to Darax The Good

    Darax The Good:
    What if the == operator was overloaded to have side effects?

    it doesnt use the == operator though!

Leave a comment on “Ask Thrice and Ye Shall Receive ”

Log In or post as a guest

Replying to comment #:

« Return to Article