SPUG: Re: DBI shortcomings
John Cokos
jcokos at ccs.net
Wed Aug 16 14:01:02 CDT 2000
They could very easily be improved.
Think out of the "developer" mode and into "end user" mode.
You write an app, that has a form that a user inputs data into
and your app updates or inserts accordingly.
The user enters "A1235" as their zip code, and your insert/update
will bomb, and DBI::errstr will return a nice generic warning.
With a wrapper, you could do the call as I'd proposed, and
before running the insert (based on a schema/definition file)
the routine would look at it, and retun an error that states:
Your entry of [entry value] for the [fieldname] contains non numeric data, please re-enter
Much more meaningful to the user, and you save the expense
of the sqlengine trying and failing. On a busy application, that
expense could be quite a large savings.
That's only a simple example, and you could programatically replicate
the error checking in your regular program, but encapsulating
it into a single line call would be beautiful.
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 11:55 AM
Subject: Re: SPUG: Re: DBI shortcomings
>
> Good points. $DBI::err and RaiseError facilities are pretty basic. The
> only explanation I've seen of this is that these are the greates common
> denominator between all the DBD database modules. How could these be
> improved? The getting all results back as an array of hash references
> would be a nice feature, however, my understanding is that each hash still
> has to be built by the DBI, and having to create all of those columns
> as keys would be very costly.
>
> It might be cool to have a function that returns an array of tied hashes,
> and those hashes index the array that selectall() returns. It would be
> convenient, and more efficient.
>
> cody
>
>
> On Wed, 16 Aug 2000, John Cokos wrote:
>
> > 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/
> >
> >
> >
>
>
>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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/
More information about the spug-list
mailing list