Good practice: always define buffers? - Forum - OpenEdge Development - Progress Community

Good practice: always define buffers?

 Forum

Good practice: always define buffers?

This question is not answered

Hello,

What code do you like the most, left or right? See screenshot in link below:

https://drive.google.com/a/tvh.com/file/d/0B1P8s6ZKpj7wSnVTLVNONW1laVU/view?usp=drivesdk

Please elaborate why? I'm very interested in the answers.

All Replies
  • Apart from the fact that the right hand one won't work (not all references to Company have been updated), I think the left is better. It's good practise to do your updates on a buffer with a strongly scoped transaction block, but using buffers elsewhere isn't necessary.

    My opinion of course.

  • Your opinion is wrong ;)

    Because this is an internal procedure you very much want to use a buffer scoped to the IP.  If you just allow "free references" willy nilly you will be elevating the scope of the default buffer to the procedure block and causing unintended side-effects.  Even if all you do is NO-LOCK reads this is a bad thing.

    My preferred approach is to include buffer definitions such as:

    define buffer customer for customer.

    for all of the tables referenced in an internal procedure.  This ensures that no accidental side effects occur due to unintended references to the default buffer.  Of course you should also define a distinct "update" buffer and use strong scope for any updates -- that's a second buffer.

    --
    Tom Bascom
    tom@wss.com

  • Ditto on what ChUIMonster said.

  • BTW -- the "buf" prefix and other junk (like "l") is hideous.   Cluttering up your names with noise about the datatype makes your code unreadable gibberish.

    FIND FIRST to find a unique record is also an abomination.  Suppose there are two or more companies meeting your criteria?  Why aren't  you dealing with the rest of them?  Or at least throwing an error that there should only be one?  Why is the one that you just found magic?

    --
    Tom Bascom
    tom@wss.com

  • Hi Tom,

    FIND FIRST to find a unique record is also an abomination.  Suppose there are two or more companies meeting your criteria?  Why aren't  you dealing with the rest of them?  Or at least throwing an error that there should only be one?  Why is the one that you just found magic?

    I disagree with this.  If you know that the records are unique and a FIND will never return more than one record then FIND FIRST will actually save you a wee bit of time because the ABL doesn't have to do its check for duplicates (i.e. the AMBIGUOUS function).  Outside of that corner case you are correct.

    Brian

  • huh? you only know records are unique if there is a unique index defined (and the damn fields that make it are mandatory and not null)… but then if the developer ‘knows’ that so should the ABL and don’t waste any time to check for anything :)


    Marian Edu

    Acorn IT 
    +40 740 036 212

  • Nope.  This is how it works and the info came straight from Mary Szekeley's mouth. By default we do what we need to do to determine if AMBIGUOUS should return true/false and by using the FIRST phrase you are telling us that you don't care about ambiguity so we don't do the work.

    By the way, we are talking about nanoseconds here so for most people it won't really matter but for those who need to remove every unneeded nanosecond this will matter.

  • With all due respect I think you are perpetuating a myth.  There is no check for ambiguity on a unique find -- I have never found an iota of evidence to support that contention.  If the FIND is using a unique index there is no need to check anything -- the very nature of the index ensures that.  If it is *not* a unique index then you should be using a statement that deals with multiple records such as FOR EACH.

    Even if I am wrong (I'll happily buy you lunch if you can show that I am) -- the statement is still misleading the next programmer to come along and, in my mind, the downside of misleading code far outweighs any hypothetical minuscule saving of execution time.  FIND FIRST is waving a flag saying that there could be multiple records -- but then doing nothing about the possibility.

    --
    Tom Bascom
    tom@wss.com

  • BTW, I've talked to Mary about this too -- and I didn't hear what you heard.  Maybe we asked slightly different questions?

    --
    Tom Bascom
    tom@wss.com

  • Tom,

    It came directly from the person who wrote the code.  I stood in her office while she explained it to me many, many years ago.

    Brian

  • Tom,

    I am sure there are optimizations in the code related to the ambiguity check to make it as efficient as possible so it is likely it can detect the 'perfect scenario' and just flag ambiguity as false but I do know that it is possible that a second read has to be done to satisty the ambiguity check.

    Brian

  • Well Brian,

    if it was many, many years ago maybe it was fixed already otherwise it’s always a good time to do something about it :)

    That should be resolved even at compile time, if the runtime really need that ‘assurance’ then make the compiler ‘optimise’ the code but don’t try to justify usage of a bad statement with the limitations of the compiler/runtime :(


    Marian Edu

    Acorn IT 
    +40 740 036 212

  • Marian,

    It's my understanding that this behavior has never changed (i.e. horse left the barn long ago).

    Brian

  • I update the screenshot, I think all references are ok now. Thanks for noticing my quick copy paste mistake.

  • Like I said, I've asked Mary about it too.  I didn't video the conversation so I have to rely on my pitiful wetware capabilities but my recollection is that she said that a UNIQUE FIND with a UNIQUE index does NOT check for ambiguity.  What would it even check?  Maybe we can invite her to drop in sometime and we can have a spirited discussion :)  Or maybe we can get some of the current engineering people to weigh in on what the current code does.

    --
    Tom Bascom
    tom@wss.com