[Catalyst] Alternatives to DBIx?

kevin montuori montuori at gmail.com
Sat Apr 17 23:38:57 GMT 2010


On Sat, Apr 17, 2010 at 7:04 PM, John Karr <brainbuz at brainbuz.org> wrote:

> In my own analysis the Time and Effort to learn DBIx is greater than the Time wasted writing repetitious DBI code, the time I've already invested on DBIx has shown that there is a better way than DBI, but for me it isn't DBIx.


I'm in no way arguing with your conclusion, such as it is; however,
there's more to evaluate than just time spent learning a new library.
In my experience (two or so years with DBIC/Catalyst and many, many
more with sundry DBI hacks) DBIC code has proven trivial to maintain
and augment.  Furthermore, it's relatively easy to find programmers
who are familiar with it and can be brought up to speed quickly.  Your
situation might be different; for me the maintenance is as important
as the development.

On a different note: I rarely have a need for raw SQL: what DBIC is
generating is perfectly appropriate (and DBIC::Deploy does a bang-up
job of creating DDL).   When it is necessary, DBIC::ResultSource::View
+ native DB SQL code (stored procs, views, &c.) does a fine job of
keeping SQL out of the Perl app.  (I know that opinions on this differ
-- ha! -- but it's worked out well for me, particularly when I hand an
SP off to a DBA for optimization; as a rule I get less grief when it's
just SQL and not SQL embedded in some other language.)

k.

--
kevin montuori



More information about the Catalyst mailing list