ORM systems in Perl and Python?

Question

A database application of mine, written in Perl — using Moose and DBI and communicating with the DB server with plain SQL statements —, has got to the point where it needs a complete rewrite from scratch. This looks like a great opportunity to learn ORM. But I am at loss about which ORM system to choose. As my bread-and-butter languages are Perl and Python, I have looked at systems that seem to be the major ones in each of them — DBIx::Class and SQLAlchemy. But as both of them require quite a bit of learning, it is hard to choose in advance which one to invest my time and energy into, or whether to consider some other ORM system (Rose::DB::Object, Fey::ORM, Django ORM, SQLObject, Storm, …) instead.

Therefore I am asking people who have written ORM in both Perl and Python: what are the pros and cons of particular ORM systems in these languages? And, which one of them is, in the answerer's personal opinion and according to his/her personal experience, most fun to write in (after one has mastered it), and why?

Additional considerations:

I am equally comfortable and in love with both Perl and Python, so the choice of programming language is in itself not an issue;

as I have a pre-existing database, I am not interested in using ORM to manage databases;

I am writing for my own pleasure and do not care much about what's hot in the market;

I am not easily intimidated by steep learning curves.

(To my surprise, the Web has almost nothing helpful to say on the subject; about the only relevant statement I found was this: "DBIx::Class is not only the best Perl ORM I've used, but also one of the best ORMs in any language. It might not be the fastest or lightest ORM, but it's definitely the one with the most intelligent and flexible API" (Tobias Kremer). But this was written in 2009…)

Answer 1

I cannot speak to the Python ORM systems, but DBIx::Class (or dbic) is a nice choice if your data consists of groups of "things". If you have taken the time to normalize your database, the dbicdump command takes all the work out of defining the classes. Go on, add some foreign keys to the schema. You know you should.

The real trick is to get your head around the concept of the ResultSet. There's some DWIM when calling it in scalar context as compared to list context. Your code stops looking like db queries and starts looking like OOP. Other nice tooling is support for schema migrations that you can keep in a repository and easily upgrade/downgrade the schema.

There are arguments against ORMs. Why let someone else write your SQL for you? You can drop down to raw SQL if you need. Joining 2 tables is fine. Joining 3 or more is a pain unless you have defined the foreign keys. When to use Dbic and when not to.

I liked the way Dave Cross explains Dbic. Other tutorials are available.