Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ziggy (25)

ziggy
  (email not shown publicly)
AOL IM: ziggyatpanix (Add Buddy, Send Message)

Journal of ziggy (25)

Tuesday August 10, 2004
09:57 AM

Newfound Respect for Class::DBI

[ #20342 ]
So I finally took a look at Hibernate, the new kid on the block for lightweight persistance in Java. The docs described something so hideously complex, I stopped skimming after Chapter 1 (of 19). If I want to have object based access to a database, why do I need to use Tomcat, code generators, and XML config files? I just want simplified database access ferchrissakes!

I'm still twitching in disbelief. Class::DBI may have a lot of dependencies on modules from CPAN, but the interface itself is simple, easy to understand, and easy to use -- especially in the simple case. And I don't need to redefine fundemental constants of the universe in the process.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Remember, Hibernate is a reaction to EJB, which I believe was originally a conspiracy between Pope John XIII and the Byzantine Empire to divide up Africa.

  • Hibernate is more complex than Class::DBI, but it's not hard to use. To your specific complaints, Hibernate doesn't need Tomcat, although Tomcat is a common place to use it. It uses code generation, but so Class::DBI. In both cases, the code generation is done at run-time. It does use XML config files, and I kind of like them. Take a look at this one from the quickstart chapter:

    <?xml version="1.0"?>
    <!DOCTYPE hibernate-mapping
        PUBLIC "-//Hibernate/Hibernate Mapping DTD//EN"
     

    • Personally, my brain switches off at the sight of XML, so I find it really hard to read that example at all. Seriously.

      I'm not entirely convinced that

      __PACKAGE__->constrain_column(name => qr/\w{1,16}/);

      is that much more confusing than their XML, but the constrain_column stuff is fairly simplistic at the minute (interface wise. It's actually designed so that my base class can set up certain things to make it hook into CGI::Untaint in nice ways). I'm certainly tempted to allow:

      __PACKAGE__->constr
      • > __PACKAGE__->constrain_column(name => sub { length = 16 });

        That was even easier than I'd expected. (Other than perl needing to disambiguate via length()...)

            } elsif (ref $how eq "Regexp") {
              $class->add_constraint(regexp => $col => sub { shift =~ $how });
        |+  } elsif (ref $how eq "CODE") {
        |+    $class->add_constraint(
        |+      code => $col => sub { local $_ = $_[0]; $how->($_) });
            } else {

        Tony
      • I'm really not a big XML fan, but I think it's applied in a very reasonable way here. The constrain_column() method requires more thinking than specifying it in the XML does. I would ideally like to see more of the stuff that Tim Bunce did to auto-detect database constraints folded into Class::DBI::SomeDBD classes. He had stuff to detect the column length, not-NULL constraints, etc. and build the same constraints in the CDBI classes.

        Hibernate has many good features. Here are some of the ones I would mo

    • This is why I'm becoming less of a fan of ORM's in general every day. To me having XML config files like this feels like I'm writing the DDL *twice*.

      I'm now beginning to contemplate a strictly bottom-up ORM approach, where you would get this information dynamically instead of by hand.

      Actually, I'm starting to think ORM's are an unnecessary layer of goo.

    • Hibernate doesn't need Tomcat, although Tomcat is a common place to use it.

      Whatever. I really don't care if Hibernate or Hibernate's docs are making my skin crawl. I've been programming long enough to know that I'm looking for a thin shim that converts application-level concepts into database actions, and that I want that as a single aspect in my codebase. If the Hibernate folks are telling me that I need a full-bore seven layer burrito [pablotron.org] to use their code, I'd rather write my own CDBI-inspired abstr

      • Mapping a data model with any complexity between objects and a database is just not that simple a problem. Hibernate is pretty easy to use. It might look complex to you if you are not already familiar with current Java concepts, in the same way that Class::DBI leaves many Perl newbies scratching their heads. There is a basic assumption that you've already written some Java apps with databases and objects and thus are familiar with the terms and libraries. I wouldn't hire a Java coder who didn't know Tom
        • I'm still not swayed. Let's just call this a bikeshed and move on.

          I've written about three database abstraction frameworks in the last two years, none of which have had a dependency aside from DBI / database drivers. So it is possible, even if it doesn't scale up to handle every degenerate schema on the planet.

          That's fine. What I'm looking for is probably outside the scope of what Hibernate is trying to deliver (or, best case, what the Hibernate docs have chosen to focus on). I can live with tha

  • I was just going through the same process of getting aquainted with hibernate. I thought it would be fun to see how long it took me to get up and running with a simple class. It took 8hrs (give or take a few minutes); compared to like 30 minutes for Class::DBI using Kake's article [perl.com].

    I actually *like* the XML file since you can autogenerate the db schema with it, and also autogenerate the pojo's with it. You're right, the docs are very intimidating...but there are some good beginner articles [systemmobile.com] linked from the