Using DBI methods

Andreas Franke afranke at ags.uni-sb.de
Sun Aug 18 15:41:23 UTC 2002


> However, it seems to me that it may be worth being able to use the DBI
> methods directly. |perldoc DBI| lists those, for the interested.
> 
> Advantages:
> 
> 1) Can use stuff like:
>   my ($a, $b) = $dbh->selectrow_array("SELECT a,b FROM foo WHERE 
>                                        prim_key=7");
> 
> or selectall_arrayref, and so on
> 
> which is nicer/cleaner/faster/easier to read than our sendsql+fetch stuff

I think having short-cuts to get a single value, a single row, 
a single column etc. from the database is worth supporting; 
I've been using the following things for my application (which
doesn't have anything to do with perl or DBI, but I _am_ using
MySQL):
    
        default (this was the original generic behaviour; 
                 it returns a pair: 
                 1. a list of column names, and
                 2. a list of rows, 
                    where each row is a list of col values)
	records (perl equivalent: a list of hashes)
        tuples  (perl equivalent: an array)
        oneRow  (perl equivalent would be a list of values, 
                 one for each column; an exception is raised
                 if the result contains less or more than 
                 exactly one row)
        oneColumn (perl equivalent would be a list of values,
                   one for each row; an exception is raised
                   if the number of columns in the result
                   is not exactly 1)
        oneValue (returns the value; requires that the result
                  is exactly one row with exactly one value;
                  otherwise an exception is raised)

These values are given to my execSQL method (which corresponds to
SendSQL together with the loop fetching the result rows) as a 
'format' attribute. Note that my glue does not allow lazy fetching
of rows from the database yet (which I consider a bug in the glue
code), so this way of operation is missing from the above list.

This is not a proposal to introduce all these options for Bugzilla, 
I just want to say that I think it's a good thing to have the option
for multiple result formats, besides the generic SendSQL/fetch rows
stuff.

> 3) We need to up the required DBI version

> 4) we need to up the required perl version to 5.005_03
>   - that DBI version requires 5.005_03. We've been talking about it for a 
> while, and 5.8 is now out, so requring the latest 5.005 release shouldn't 
> be an issue, although I know that afranke will disagree...
>   - Do note that the latest DBI version has a note that it may not support
> 5.005 for much longer. This may become an issue for us at some point in
> the future.

I think requiring a recent version of DBI is not much of a problem,
and if this means that some perl versions cannot be supported any more,
so the perl version requirement needs to be up'ed. 
Just put a visible note in the release announcement and the upgrade web
page that those who are running old perl and are unwilling or unable
to upgrade that, should _not_ upgrade their bugzilla anymore until
that they have a better perl. A "last working cvs datestamp" would
be good to know as well.

> What do people think about the above?
> 
> 'Feature' removal:
> [...] 
> If you object to the removal of any of the above please let me know ASAP.

Looks like a reasonable cleanup to me. Thanks for doing all that work.

Andreas





More information about the developers mailing list