Hello all,
I have been looking at using a ORM for my next project and I came across Class::DBI and DBIx::Class on CPAN.
It would seem that DBIx::Class is a rewrite of Class::DBI with a growing user community. However, apart from talk that it "learned" from the lessons of Class::DBI, I haven't found much information about why I should choose DBIx::Class over the other.
UPDATE: And then there is Rose::DB::Object, too.
I have read the documenation of all three modules, and am able to point out some differences. But what would be good is to have a complete comparison chart with pros/cons of each.
I am starting a comparison in this thread with the little I know. I would be greatefull if you could add your input to this starter.
UPDATE: Upon reading a reply to this thread, I am now putting Rose::DB::Object as one of the modules to be compared. The corresponding pros/cons are updated and enlarged too.
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 Ima::DBI.
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 DBI (is this true?)
Distinction of "primary/essential/other/all" column kinds. (Better for performance for large columns. However, Class::DBI 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 DBI (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 Class::DBI in many cases, although it claims to have learned from the lessons.
No support for in-memory-only objects (just like Class::DBI
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 DateTime 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 Rose::DB::Object 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, Rose::DB::Object 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 Rose::DB::Object.
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, Rose::DB::Object seems to be a good foundation ORM.
For the moment, the only few downsides for me is the lack of Catalyst support, the shaky Oracle support, and the lack of UUID columns. I can deal with the Catalyst 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
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|
|
