Re: Question re SQL::Abstract (or something similar, whose existance I ignore!)

Why not just leave everything in @binds and then at execution time, loop through @binds replacing undefined values with your new ones? What about NULLs though? Neither your solution nor mine leaves the ability to insert things you *want* to be undefined. Maybe you should let SQL::Abstract build your $where and then ignore what it gives you for @binds and just use your own @binds at execution time. If these won't work for you and you use hard-coded values in the $where, don't forget to use $dbh->quote on them.

Comment on Re: Question re SQL::Abstract (or something similar, whose existance I ignore!)

Replies are listed 'Best First'.
Re^2: Question re SQL::Abstract (or something similar, whose existence I ignore!) by blazar (Canon) on May 18, 2006 at 16:03 UTC
This is almost exactly what I'm doing. Except that to keep "consistent" I set the values I want to be "undefined" to `'?'`. As I wrote, I feel uneasy with this setup. Building the whole of `@binds` at execution time sounds like being more error prone, since if I change the clause, I will most probably also have to change the code that builds it, and if I forget to, then... I will screw it all up. I'd like to minimize the chances to do so instead!	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Question re SQL::Abstract (or something similar, whose existence I ignore!)
by blazar (Canon) on May 18, 2006 at 16:03 UTC

This is almost exactly what I'm doing. Except that to keep "consistent" I set the values I want to be "undefined" to '?'. As I wrote, I feel uneasy with this setup. Building the whole of @binds at execution time sounds like being more error prone, since if I change the clause, I will most probably also have to change the code that builds it, and if I forget to, then... I will screw it all up. I'd like to minimize the chances to do so instead!

[reply]
[d/l]
[select]