Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Comment on

( #3333=superdoc: print w/ replies, xml ) Need Help??

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


    In reply to Perl ORM comparison (Class::DBI vs. DBIx::Class vs. Rose::DB::Object) by aulusoy

    Title:
    Use:  <p> text here (a paragraph) </p>
    and:  <code> code here </code>
    to format your post; it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • Outside of code tags, you may need to use entities for some characters:
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others musing on the Monastery: (7)
    As of 2014-12-25 06:13 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      Is guessing a good strategy for surviving in the IT business?





      Results (159 votes), past polls