in reply to DBI bind_param_inout trick

Dunno ... while it might work, it bothers me nevertheless ... and here is why.   Now, we have a dependency, introduced into any particular statement, upon “what statement or statements, whatever they might have been(!), that have come before.”   I-f that prior sequence of events is both “known,” and furthermore, “known to be entirely correct in all cases,” then Life Is Good.™   Otherwise, all bets are off and we have a whale of an (unnecessary...) debugging problem.   No, I don’t feel good about that ... the more I think about it ... not at all.   I feel that we have opened up a can-of-worms that, like all such cans, is better left tightly sealed.   (And I know that you know full well and as a matter of course what I mean, and what I don’t mean.)

Replies are listed 'Best First'.
Re^2: DBI bind_param_inout trick
by runrig (Abbot) on Aug 22, 2012 at 22:57 UTC
    I wasn't all that sure about it either, but it worked, so I shared. And I might use it in a pattern, where, I often insert from some hash in some loop, and I can set some constant values before the loop, and then set the changing values and execute the statement within the loop. I don't expect any more debugging problem there than I've ever had before, but we'll see... ;-)
[reply]

      Here is a pattern that I'm pretty sure would break it: 

      if( ... ) {
    # Over-ride default just for now:
    local $hsh{status} = 'backlog';
    $sth->execute();
    ...
}

      [download]

      Just FYI, as the most mundane thing that occurred to me when trying to think of ways this might break or just surprise someone. delete would also be a no-no (but I found that unlikely to be a 'trap').

      Hash values are actually pretty "stable" regarding references to them, as far as I can imagine. :) (But, yes, I'd only use this trick within a fairly small scope.)

      - tye        

[reply]
[d/l]

In Section Meditations