On Sat, Apr 17, 2010 at 7:04 PM, John Karr <brain...@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 _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/