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