Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Why did DBIC overtake CDBI?

by mattr (Curate)
on Sep 12, 2006 at 16:17 UTC ( #572567=perlquestion: print w/ replies, xml ) Need Help??
mattr has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks,

In "DATABASE ACCESS WITH DBIx::Class", the Catalyst Manual says, "Although Tony Bowden's Class::DBI has been the traditional Perl ORM (object relational mapping) engine, Matt Trout's DBIx::Class (abbreviated as "DBIC") has rapidly emerged as the Perl-based ORM technology of choice. Most new Catalyst applications rely on DBIC, as will this tutorial."

As it happens I've always used CDBI and HTML::Template but Catalyst likes DBIC and Template Toolkit so I'm planning on doing the switchover.

I don't mean to start a flamewar, but I'd like to know why. I've felt CDBI is too slow. Any monks with experience using both in or outside of Catalyst? Thanks.

Comment on Why did DBIC overtake CDBI?
Re: Why did DBIC overtake CDBI?
by rinceWind (Monsignor) on Sep 12, 2006 at 16:33 UTC

    There were some talks given at YAPC::EU on this subject and related matters. I point you to davorg's slides What's wrong with ORM, which I think should really have been titled "What's wrong with Class::DBI" as DBIC has fixed many of these issues.

    In another talk, Matt Trout explained the positive vibes in the community which have made DBIC a success, and exceeded his initial ambitions.

    I'm using CDBI for some database application stuff (not web stuff). Although it's slower than raw DBI SQL, this is to be expected. The main problem I have is that I had to modify CDBI to get it to work with Sybase mixed case columns; I submitted a patch to Tony Bowden, but this patch has not been accepted. I'm currently reviewing DBIC with a view to migrating.

    --

    Oh Lord, wonít you burn me a Knoppix CD ?
    My friends all rate Windows, I must disagree.
    Your powers of persuasion will set them all free,
    So oh Lord, wonít you burn me a Knoppix CD ?
    (Missquoting Janis Joplin)

      No offense to davorg, but that talk was obsolete years ago. Class::DBI has plenty of auto-discovery tools. There's no reason you'd have to hard-code those things if you don't want to.

        I know that Class::DBI::Loader will automatically load tables, columns and relationships. But does it, for example, automatically turn DATETIME columns into DateTime objects[1]? Or use column types to determine valid values for attributes?

        The talk is a bit badly organised. The examples are all in Class::DBI (as that's what I was using when I originally wrote the talk) but the lists of items that an ORM should handle shouldn't be taken as a list of things that Class::DBI doesn't do. If anything the talk is a reaction to the number of obvious things that ActiveRecord doesn't do.

        As I said in the presentation at YAPC, the talk is misnamed. Even when I first wrote it, it should have been called "What's Wrong With Some Current ORM Implementations". These days, it should really be called something like "Things To Look For When Choosing An ORM".

        [1] The key word here being "automatically". I know you can use the inflate/deflate functionality, but as far as I know you need to set that up explicitly.

        --
        <http://dave.org.uk>

        "The first rule of Perl club is you do not talk about Perl club."
        -- Chip Salzenberg

      Great, thanks for pointing me to the slides.
Re: Why did DBIC overtake CDBI?
by Mutant (Priest) on Sep 12, 2006 at 17:03 UTC
    I haven't used DBIC myself, but I've used CDBI for several projects, and had a look at the docs for DBIC (plus some of my colleagues have used it).

    AFAICT, DBIC seems to be superiour. Besides the fact that it's actively maintained by some of the key people in the Perl community, it offers several features that were difficult to achieve using CDBI.

    One of the most important of those is the ability to select across criteria from multiple tables (i.e. joining on other tables, and returning objects based on a certain criteria across all those tables). In CDBI you are limited to the table your object maps to, unless you roll your own.

    DBIC also has full support for many to many relationships, which seems fairly fundamental to me. In fact, I think the limitations in CDBI are due not to the fact that the no one's gotten around to implementing them, but because its design makes implementing these things extremely difficult. (I have to admit, having had only a cursory look at the CDBI code, I'm basically speculating here).

    Although you didn't ask about it, one of the main limitations in HTML::Template in working with ORM's is that you can't pass it an object directly (I think HTML::Template::Plugin::Dot gets around this, but I haven't tried it).

    Of course, Catalyst doesn't prevent you in using any of these systems. If it did, I'm sure it wouldn't be as successful as it has been.
      Although you didn't ask about it, one of the main limitations in HTML::Template in working with ORM's is that you can't pass it an object directly (I think HTML::Template::Plugin::Dot gets around this, but I haven't tried it).
      HTML::Template::Compiled also supports objects. (and CGI::Application and Catalyst both have a plugin/view class for it)
Re: Why did DBIC overtake CDBI?
by perrin (Chancellor) on Sep 12, 2006 at 17:08 UTC
    Class::DBI is fairly basic in terms of the SQL it supports, and will often do things in a way that is not very efficient. Rose::DB::Object and DBIx::Class both make more of an effort to handle sophisticated database queries and write efficient SQL.
      one thing about CDBI's lack of joins is that classes can have relationships mapped to other classes that live in other databases. do you know how DBIC handles this (i.e., transparently?)?

      (aside: one thing that bugs me about the various ORM solutions is that they want to handle their own db connections and want me to provide DSNs instead of $dbhs. with CDBI this is relatively easy to get around by overriding My::CDBI->db_Main(). is it that easy with RDBO or DBIC?)

        Rose is flexible about how connections are provided. I'm not sure if there's an easy way to use it to fake joins across databases though. That would be a good question for the mailing list.

        I can't answer your DBIC questions because I haven't used it. I'd suggest posting a top-level question or asking on the mailing list.

        aside: one thing that bugs me about the various ORM solutions is that they want to handle their own db connections and want me to provide DSNs instead of $dbhs. with CDBI this is relatively easy to get around by overriding My::CDBI->db_Main(). is it that easy with RDBO or DBIC?

        In Rose::DB::Object, the database connection is abstracted by a separate class (Rose::DB). Each RDBO object "has a" Rose::DB object, and each Rose::DB "has a" plain old DBI $dbh. If you want to get your $dbh from elsewhere and use it with RDBO, all you need to do is override init_db() in your common RDBO base class to get your $dbh, shove it into a Rose::DB object, and return it.

        The database connection is "object data" in the world of RDBO and can be passed in (or swapped out) just like any other piece of data, on a per-object basis if needed. You can even load an object from one database and save it into another by swapping db objects between load() and save() operations.

        (Thanks to some semi-heroic column type abstraction, you can even do this if the database software is different in the two databases (e.g., load from MySQL and save into Postgres). There's an example of this in the tutorial.)

        (aside: one thing that bugs me about the various ORM solutions is that they want to handle their own db connections and want me to provide DSNs instead of $dbhs. with CDBI this is relatively easy to get around by overriding My::CDBI->db_Main(). is it that easy with RDBO or DBIC?)

        With L<DBIx::Class::Schema> you can do this quite simply:

        package MySchema; #... setup schema stuff here ... __PACKAGE__->connection(sub { # Do whatever you want to do to build your $dbh return $dbh; });

        We're not surrounded, we're in a target-rich environment!
Re: Why did DBIC overtake CDBI?
by mattr (Curate) on Sep 13, 2006 at 14:36 UTC
    Wow, I'm really happy with the responses. Even the ones about HTML::Template vs. Template::Toolkit which I was afraid to ask at the same time.

    I have experience with CDBI and think I know its quirks, plus the Catalyst::Enzyme module seems to be useful with it from reading the docs, but because of the responses above I'll invest time to learn about how DBIC can save me from carpal tunnel and do other great things. Thank you very much.

      plus the Catalyst::Enzyme module seems to be useful with it from reading the docs

      That's only because I only had experience with CDBI at the time, and then I haven't had the time or motivation to make it also handle DBIC and/or Rose::DB::Object. I would like to, but I don't see it happening in the near future.

      /J

Re: Why did DBIC overtake CDBI?
by jk2addict (Chaplain) on Sep 19, 2006 at 17:44 UTC

    Sorry I'm late to the party. :-) As the author of Handel, I've lived in both camps. I started with CDBI, and converted to DBIC. The community and past internet argument explosions aside surrounding CDBI, there were two main reasons I moved towards DBIC.

    First, DBIC seems to make more of an effort to get out of my way if I want it too. I can delegate to it, or an instance of it (via Schema), rather than having to be it (@ISA Class::DBI). This means I can take a bottom up approach to my DBIC based application; whereas a CDBI based application seems to start at the top and work downword.

    Second, DBIC provides an insane amount of flexibility and configuration. There's an option of accessors for just about any step in the process. IT allows me to do things I'd never try with CDBI; things like interchanging schemas into the same app code; being able to inject columns, components, constraints, validaiton, etc into schemas and table objects on the fly...even into instance of table classes, rather than the table class itself.

    If you need to do magic, DBIC is more capable of it IMHO.

      Wow, thank you that is a great comment. It makes me want to start from scratch and read everything about DBIC to get all the power out of it you mention and which I had not realized having just dipped in to relevant parts here and there and starting to explore up and down it.

      Matt

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://572567]
Approved by Old_Gray_Bear
Front-paged by grinder
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (6)
As of 2014-08-02 10:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Who would be the most fun to work for?















    Results (55 votes), past polls