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.
 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"
     

    • 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
      • 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 most like to have:

        • Built-in support for mapping of inheritance.
        • Efficient many-to-many support, including support for search criteria on the mapping table.
        • Support for flexible object and query caching. (I plan to work on this.)
        • Built-in support for fetching a graph of related objects in one SQL statement (like the recent question on the mailing list about fetching an object and it's might_have relation in one shot).
        • Optimistic locking. This wouldn't be very hard to add, I think.
        • More extensive support for collections, like delete_from_* (as opposed to add_to_*) and mapping of related objects to sets, rather than just arrays.