Re: [Poop-group] specify bind_param in Class::DBI

[Tod H. <th...@gi...>]

You know, back in the old days when I was building the OOP extensions for 
JFORTH Leo Brodie told me "don't do at run time what you can do at compile 
time"...

I think that sentiment is appropriate here. It might seem awefully nice to 
build a piece of code that can handle any possible schema on the fly, but it 
would be VASTLY simpler and more efficient to just build a script that 
analyzes your database schema, maybe using a map file (check out the xml2dbms 
project for some advanced thinking on mapping schemas) and generates the 
class code you want. 

Now you have a very efficient class, and if you do change your schema all you 
have to do is regenerate it. If you templatize things using Text::Template 
for instance you can quite easily allow for regenerating even a customized 
version of a class, and you can rapidly spit out boilerplate classes for new 
projects in minimal time. You could of course also use something like m4 and 
make, whatever suites your fancy.

Besides, I suspect that no amount of tweaking is going to let you build SQL 
that will handle all the possible schemas people are likely to want to use. 
Better to generate code and let them adapt it to their needs.

On Tuesday 23 April 2002 12:20, Michael G Schwern wrote:
> On Wed, Apr 24, 2002 at 12:52:23AM +0900, Tatsuhiko Miyagawa wrote:
> > P.S. how is the multiple key patch going? ;)
>
> WRT that.  Your patch appears to do exactly what I was hoping to avoid.
> That being having to constantly check whether or not an object has multiple
> primary keys.
>
> Currently, you can safely say, for example:
>
> __PACKAGE__->set_sql('Foo', <<'');
> SELECT %s
> FROM   %s
> WHERE  %s = ?
>
> sub foo {
>     my($self) = shift;
>
>     my $sth = $self->sql_Foo( join(', ', $self->columns('Essential')),
>     	                      $self->table,
> 		              $self->columns('Primary')
> 			    );
>     $sth->execute($self->id);
>     ...
> }
>
> putting aside the redundant nature of that method, the point is I can trust
> that for any Class::DBI object I know that $self->columns('Primary') is
> going to return one column and $self->id is going to return one value and
> $self->table is going to return one table and that's enough information to
> retrieve that object.
>
> Once you get into multi-column primary keys implemented as a simple list,
> you have to check *every time* to see if the object you were handed has
> multiple columns & values coming in and complicate all your code and SQL to
> account for that.  I really don't like that.
>
> OTOH, I haven't come up with anything better.