Hibernate Metadata Explored

JSR-175, standardized metadata, may have more potential to simplify configuration of Hibernate than of Struts. Why do I say this?

  • Hibernate has a one-to-one relationship between mapped objects and mapping files.
  • Shortcomings in XDoclet make it impossible to generate composite-id mappings, so there’s an immediate value-add.
  • Unlike Struts, there’s no large configuration file shared by the whole framework. is small and used only for configuration.
  • The mappings are generated at the attribute level, so more of the bindings (return type, etc) can be determined by reflection rather than the user needing to enter them (Xdoclet can generate this).

Let’s take a look at an example (supplemental code will be at the bottom):

@HibernateMapping( table="employees")
public class Employee
    private Name name;  //Yes, name as primary key is dumb
    private String job;
    private Date startDate;

      @HibernateCompositeIdAttribute(name="firstName", column="first_name"),
      @HibernateCompositeIdAttribute(name="lastName", column="last_name")
    public Name getName() { return name;}

    public Date getStartDate() { return startDate; }

    public String getJob() { return job; }

    //The setters go here

In this case, the metadata approach almost matches the line length of the XDoclet tags to accomplish the same task, and as mentioned, exceeds XDoclet’s capabilities in capturing the composite-id in metadata. (Don’t get me wrong, I like and use XDoclet.)

Don’t give me this story about the advantage a separate config file gives you (in this specfic case). There’s 2 main types of change that affect an hbm.xml file – one is changes to the class. That’s where the existing approach can be a pain – you have to add/remove/change the attribute in the class and the mapping. The other case is a database change, which isn’t a trivial thing. The planning that goes into making changes to a production database can certainly include planning to change the metadata and rebuild your app. It could help you if you have different table and column names in your different environments, but that sounds like a recipe for disaster anyhow.

Because annotations can be reflected at runtime, Hibernate could automatically detect @HibernateMapping classes and add them to its Configuration. Clearly, an @Configuration annotation would be needed to specify some configuration parameters, and could even give a limited classpath to search (e.g. com.kischuk.*) to speed the search for persistable classes. The metadata approach also causes at least some constraints on the format of the metadata to be enforced at compile time rather than runtime.

Supporting code follows (4 different interfaces):

public @interface HibernateMapping
   String table();

public @interface HibernateAttribute
    public String column();

public @interface HibernateCompositeId
    public HibernateCompositeIdAttribute[] value();

public @interface HibernateCompositeIdAttribute
    public String name();
    public String column();

3 thoughts on “Hibernate Metadata Explored

  1. “large configuration file shared by…”
    That’s your first mistake. You should be breaking your forms and mappings down into sizable chunks via multi-config.

    “Struts”…the other white meat!!

  2. Good call, James. Certainly I wasn’t intending to say that struts-config is monolithic and unwieldy. The addition of modules to Struts was an important advance for Struts and comes highly recommended – I am curious what granularity you suggest for this.

    I meant more to highlight the difference when compared to Hibernate. If Struts were configured like Hibernate, you’d have one config file for the ControllerServlet, and a config file for each action class. (And you’d need to add the Actions to the controller servlet somewhere in code.) I think the struts approach is fine, just not as conducive to direct translation to JSR 175 Metadata.

  3. Good use of the metadata Rob this would make things pretty interesting.

    I guess my question is why do you even want to use Struts when there are much better frameworks out there. Of course there is the corporate standard sure, but WebWork might provide an easier mapping to the metadata concepts.

Comments are closed.