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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Newfound Respect for Class::DBI 9 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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"
        "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd">

    <hibernate-mapp ing>

        <class name="net.sf.hibernate.examples.quickstart.Cat" table="CAT">

            <!-- A 32 hex character is our surrogate key. It's automatically
                generated by Hibernate with the UUID pattern. -->
            <id name="id" type="string" unsaved-value="null" >
                <column name="CAT_ID" sql-type="char(32)" not-null="true"/>
                <generator class="uuid.hex"/>
            </id>

            <!-- A cat has to have a name, but it shouldn' be too long. -->
            <property name="name">
                <column name="NAME" length="16" not-null="true"/>
            </property>

            <property name="sex"/>

            <property name="weight"/>

        </class>

    </hibernate-mapping>
    This provides two constraints, and id generation from the program rather than the database. Doing those things in Class::DBI would require writing a constraint method and a trigger method, and is generally more confusing. One idea I've had is to write something that would allow Class::DBI classes to be configured with an XML file like this. So far though, I haven't used the constraints enough to make it worth the trouble.

    Class::DBI is pretty good for a simple O/R mapper, but Hibernate has a much more complete feature set. If there was a full-featured port of Hibernate for Perl, I would definitely be using it instead of Class::DBI.

    • 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

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.