Agreed, but theres no error checking/validation built in.
And what if you want back an array of hashrefs? Can't
do that with DBD, but with a wrapper, you sure can.
John
========================================
John Cokos, President / CEO: iWeb Inc.
http://www.iwebsys.com
jcokos at ccs.net
========================================
----- Original Message -----
From: "Aryeh "Cody" Sherr" <asherr at cs.unm.edu>
To: "John Cokos" <jcokos at ccs.net>
Cc: <B.Ingerson at epixtech.com>; <spug-list at pm.org>
Sent: Wednesday, August 16, 2000 10:33 AM
Subject: DBI shortcomings
>
> Actually, there are some often overlooked shortcuts in DBI that I would
> like to share in response to your statement that DBI is long winded:
>
> $dbh->do($statement, \%attr, @bind_vals)
> do prepares, binds, and executes a non SELECT statement
> so your example would be:
>
> $dbh->do("UPDATE some_table SET cola=?, colb=?", undef, $vara, $varb);
>
> in one line. if you use bind variables, you also don't have to quote the
> values in $vara and $varb to prevent them from mangling your SQL
> statement, quicker and less error prone.
>
> @my_arr = selectrow_array($statement, \%attr, @bind_vals)
>
> selectrow_array prepares a SELECT statement, binds the values, and fetches
> your first row back all in one statement.
>
> There are more, such as prepared statement handles, the NAME_lc and
> NAME_uc attributes, and several other functions that not only take fewer
> lines of code but are also easier, faster, and more efficient. For
> sources, I recommend the DBI man page or the Perl DBI book from Oreilly.
>
> Cody Sherr
>
>
> On Wed, 16 Aug 2000, John Cokos wrote:
> > Just some thoughts on the CPAN module to be written ...
> >
> > We kicked around a few ideas last evening, but never really
> > came to a final resolution on what the actual project will
> > be. Seems like there were a lot of application ideas presented,
> > but not many actual usable module ideas.
> >
> > So perhaps we could think of dividing our efforts into 2 parts
> > one: an appication, and two: a generic usable module.
> >
> > My personal preference is a module. My proposal is one
> > that I mentioned to a few people at Rock Bottom after the meeting:
> >
> > a Wrapper for DBI. I've gotten a good start on this, but it's
> > really a mess and needs TLC. Anyone that's coded with DBD
> > can relate to it's shortcommings, and how much code it can take
> > to get simple things done. The module I propose is a wrapper.
> >
> > Consider:
> > Current DBI Way:
> > my $SQL = qq^
> > UPDATE sometable SET
> > somecolumn = '$input{somevalue}',
> > somecolumn = '$input{somevalue}',
> > somecolumn = '$input{somevalue}',
> > somecolumn = '$input{somevalue}',
> > somecolumn = '$input{somevalue}',
> > somecolumn = '$input{somevalue}',
> >
> > ^;
> > ========================================
> > John Cokos, President / CEO: iWeb Inc.
> > http://www.iwebsys.com
> > jcokos at ccs.net
> > ========================================
> >
> >
> >
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > POST TO: spug-list at pm.org PROBLEMS: owner-spug-list at pm.org
> > Subscriptions; Email to majordomo at pm.org: ACTION LIST EMAIL
> > Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
> > For full traffic, use spug-list for LIST ; otherwise use spug-list-digest
> > Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/
> >
> >
> >
>
>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
POST TO: spug-list at pm.org PROBLEMS: owner-spug-list at pm.org
Subscriptions; Email to majordomo at pm.org: ACTION LIST EMAIL
Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
For full traffic, use spug-list for LIST ; otherwise use spug-list-digest
Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/