Heretical Perl: Writing Catalyst Apps with no ORM
SF.pm X-President Quinn Weaver will be speaking at Mother Jones on October 26th for our October SF.pm meeting.
Catalyst is the leading web MVC framework for Perl. Normally, Catalyst apps use an ORM to communicate with the database. While ORMs can be convenient, they can also hurt performance, tie your app to one database schema, and make complex queries difficult.
But this is Perl, and TMTOWTDI applies: There’s More Than One Way To Do It.
In this talk, Quinn take you through the code of a working Catalyst app that uses stored procedures rather than ORM queries as its interface to PostgreSQL. Along the way, Quinn will touch on a number of useful modules and pragmas such as DBIx::Connector, aliased, Template::Declare, and Test::XPath.
Credits: this talk is based on an app Quinn wrote with David Wheeler as a side project at PostgreSQL Experts. Thanks to David for coming up with the methodology, and writing the (IMO) greater share of of the code, including DBIx::Connector and Test::XPath.
Announcement posted via App::PM::Announce
I blog about Perl.
Back when I was an MSSQL jockey, this was taught in some places as best practice, unfortunately the stored procs were in T-SQL, not in one of many PL/* languages (including Perl) that PgSQL sports. While it may be billed as 'No ORM', it could be implemented (and I have implemented this) in an ORM fashion, with CRUD methods on 'objects' (views over tables) as separate SPs, f.e. account_{search,add,delete,update}, moving the ORM up to the database. Not sure what relational purists / oo fanboys would make of that combination though, heh.
I won't be in town for the SF.pm meeting but I will still get to hear Quinn's talk at PgWest 2010.
"While ORMs can be convenient, they can also hurt performance..."
It really depends. If you just need to run a couple of queries, then doing it through a dbh (using DBI or DBIx::Connector) is fine, however if what you need is far complex than it, for instance data collapse, drill-down/up, filtering, stats, etc, because just "running one or a couple of queries" possibly couldn't give you info that matters anyway, thus you will need to implement those features on your application codebase which would be very near to an ORM's one, except that it will be probably less efficient and with a poor API.
"...tie your app to one database schema"
It's not truth if you use DBIx::Class, see:
https://blogs.perl.org/users/kaare/2010/10/dbix-class-and-database-schemas-in-postgresql.html
"...and make complex queries difficult."
Never had such issue using DBIC. You can get access to ->dbh or even better wrap your query in a view and then use DBIx::Class::ResultSource::View.