Re: [cgiapp] Re: Writing the CGI::Application book

[Sam Tregar <suppressed>]

On Sun, 25 Jan 2004, Richard Dice wrote:

> > I honestly couldn't disagree more. [deletia]
>
> Class::DBI could indeed be underpowered to handle the kind of
> complicated cases that you describe.  [ Could Tangram be the answer
> there, though?  It has much more evolved object relationship mapping
> semantics. ]

That could be.  My evaluation was necessarily cursory.  I've never
actually used any of the modules I so casually discarded.

> [ However, did you know that you can directly write
> arbitrary SQL, execute and object-wrap the query returns from within
> Class::DBI?  Maybe this would allay your concerns with it. ]

Did you know you can do the same thing in just a few lines of Perl
code?  And those lines will be a lot easier to debug and maintain
later (see reference to my cursing colleague for proof!).

> My experience with SQL & DBI is that it quickly becomes unwieldy.  I
> guess my question is, what kind of "SQL/DBI helper" techniques are you
> using to reign in the unwieldy-ness?

None.  When the model objects need an answer from the database they
use DBI to get it.  There's a module to maintain persistent
connections and handle admin tasks, but I'm sure that's not what you
meant.

Of course, we've got the usual code reviews, coding standards and
automated testing to back us up.  And a careful, simple database
schema to start with.

What exactly is so "unwieldy" about using DBI directly?  Are you
afraid of SQL?  I know I was when I started out - the first thing I
did was write a cheesy OO wrapper.  But later, when I became more
comfortable with SQL, I came to realize that the wrapper was generally
more trouble than it was worth.

> There are a number of CPAN modules that typify each technique.  [ E.g.
> SQL::Snippet for collecting all SQL and sticking it in out-of-the-way
> places

I would use this technique if I had a dedicated DBA that only worked
on the SQL and didn't know much Perl.  That's why I use HTML::Template
- so HTML designers can work on the HTML.  But when all the SQL is
being written and maintained by the same programmers that write the
modules...  it's not obvious to me that the benefits outweigh the drag
on development.

> DBIx::Recordset for object wrapping of SQL queries for
> managability. ]

I thought this was just another OO DB wrapper, but I don't remember
looking too closely.

> However, "naive" use of DBI w/embedded SQL with the standard kind of
> prepare/execute/fetchrow loop seems like flaming death to me.

Well, I like selectall_arrayref() myself, but we're using MySQL so
prepare() doesn't get us very much.  Other coders on the project used
the usual prepare()/execute()/fetch() to good effect.

-sam

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed