Perl ORM comparison (Class::DBI vs. DBIx::Class vs

From:

Class::DBI

Pros (Class::DBI)

• Mature and stable code (However, apparently with some unstabilities across versions, see below.)
• Good documentation. (IMHO)
• Ability to easily execute arbitrary SQL with set_sql from the ancestor .
• Support for client-side triggers.
• Straightforward syntax for search (but less powerfull).
• Possibility to automagically and dynamically load metadata from an existing database following a certain non-customazible convention. (is this true?)
• Customizable column inflation/deflation.
• Seemingly, supports all databases supported by (is this true?)
• Distinction of "primary/essential/other/all" column kinds. (Better for performance for large columns. However, is otherwise the worst performer apparently!)
• Supports UUID columns. (with a PlugIn).

Cons (Class::DBI)

• Seemingly shrinking user community.
• Single author => single point of failure
• Less frequent updates to the code.
• Less memory friendly.
• No support for in-memory-only objects
• Less powerfull search syntax (but simpler to use)
• No support for creating the database from class metadata (is this true?)
• No built-in support for MANY-TO-MANY relations.
• No support for static class metadata generation.
• Doesn't really suport multiple existences od the same object on different databases, since the connection is setup from the object.
• Does NOt have seamless support for handy database domains (production, test, dev, staging, ...) and types (main, archive, reporting, ...).

DBIx::Class

Pros (DBIx::Class)

• Already large and growing user community
• Less preferable documentation. (IMHO)
• Memory friendly for large result sets.
• Ability to perform late execution of searches
• Ability to succesively narrow down the search by calling search multiple times on the ResultSet
• Possibility to automagically and dynamically load class metadata from an existing database following a certain non-customazible convention.
• Possibility to create the database from class metadata albeit following non-customizable conventions.
• Seemingly, supports all databases supported by (is this true?)
• Suports multiple existences od the same object on different databases, since the connection is setup from the schema.
• Supports UUID columns. (with a PlugIn).
• Support for MANY-TO-MANY relations.
• Support for static class metadata generation

Cons (DBIx::Class)

• Relatively young code (since 2005) -- though, apparently, with a relatively stable interface. BUT the author states in the documentation that it may change any time!
• Multiple contributions => less coherence expected.
• Reproduces in many cases, although it claims to have learned from the lessons.
• No support for in-memory-only objects (just like
• No client-side triggers.
• Executing aribtrary SQL is more cumbersome (You have to set up a ResultSource for this. Note that executing arbitrary SQL may be considered by some as bad practise for an ORM.)
• The search syntax is quite complex and cumbersome.
• Does NOT have seamless support for handy database domains (production, test, dev, staging, ...) and types (main, archive, reporting, ...).

Rose::DB::Object

Pros (Rose::DB::Object)

• Single author => coherent interface
• Getting popular with a growing user base.
• Excellent documentation. (IMHO)
• Best performance (apparently)
• Support for in-memory-only objects.
• Memory friendly (if you choose it to be) with real iterators that fetch data with the next() call.
• Built-in support for MANY-TO-MANY relations.
• Possibility to automagically load metadata from an existing database following a certain -customazible- convention.
• Support for static once-only generation of class metadata from an existing database for better performance and custamization (later, this is typically copied, pasted, and edited by the programmer.)
• Good balance of complexity, usefullness, and cumbersomeness of query syntax (IMHO)
• Supports inner and outer JOINS seamlessly in queries thanks to require_objects and with_objects constructs.
• Meaningful non-customizable defaults for column inflation/deflation. For example DATE and TIMESTAMP columns get inflated into objects. Support for BOOL is there too.
• Lazy inflation/deflation of column values. (Good for performance.)
• Supports the innovative concepts of database domain(production, test, dev, staging, ...) and database type (main, arcvhive, reporting, ..). The actual default database that is accessed by the application can be very easily and centrally modified.
• Suports multiple existences of the same object on different databases, since the connection is setup from the Rose::DB derived object.

Cons (Rose::DB::Object)

• Relatively young code (since 2005) -- though, apparently, with a relatively stable interface.
• Single author => single point of failure
• Only supports pg, MySQL, SQLite, and Informix for the moment. Oracle support is there but apparently not full.
• No support for creating the database from class metadata.
• Column inflation/deflation is not customizable but have relatively rich and meaningful defaults.
• No client-side triggers. (but cascading deletes and loads are supported.)
• Executing arbitrary SQL is really hard to get at (need to use DBH directly) and there is no bridge between that SQL and the ORM. (is this true?) Note that some consider executing raw SQL in an ORM as bad practise anyway. Besides query syntax is rich enough (with joins and all) that you may not ever need it.
• No distinction for "primary/essential/other/all" column kinds except for primary key. (Maybe a performance issue for large columns. However, apparently, is otherwise the best performer.)
• No support for UUID columns.

 

Please help making this comparison a more complete work with your knowledge! Especially in those areas where it is marked "is this true?".

Perhaps I am missing some very obvious stuff.

UPDATE:

CONCLUSION (TENTATIVE)

My humble conclusion, for the time being, is to go with .

The reason behind this choice is the execellent documentation, seemingly coherent and well-thought-of interface, the good performnace (reported), the ability to use in-memory objects, and the clear and realtively concise query syntax. Though, not yet complete, seems to be a good foundation ORM.

For the moment, the only few downsides for me is the lack of support, the shaky Oracle support, and the lack of UUID columns. I can deal with the stuff as Catalyst does not require the Model to be really compliant, but I have to find an -elegant- way for the UUID columns. As for Oracle, I am gambling on the fact that the author will finish up the support before I need to use Oracle (My next project will be on Pg).

One possible potential problem for the future may perhaps be the -relative- difficulty of executing arbitrary SQL. One possible use is Pg full-text search (available since v8.3). This haunts me as it may not be easy to fix. (Is this true?)

Cheers

Ayhan