Nilesh Kapadia

Although I had heard about it before, I had never actually tried out Hibernate Synchronizer. I was using Middlegen to generate my Hibernate mappings as well as the Java classes for my domain objects (which I think is actually using some of Hibernate's own tools to generate them from the mappings). The Middlegen generated mapping files tended to have a lot of imperfections in them, mainly in the name of properties for objects involved in relationships (one-to-many, many-to-one, etc). It would name the property to that of the name of the class, which was often inappropriate. If there was more than one relationship property with the same class type, it had a different scheme that would disrupt the existing code in a project (for which refactoring ahead of time might help prevent, but still an inconvenience). There were also some bugs I discovered where sometimes two properties were named with the same name, named with a starting capital letter (defying Java convention), or incorrectly read from the database. To solve all these issues, I was doing a lot of regexp replace (in the Ant script), but that tends to get unmanageable after a while. In the end, although Middlegen may provide a good starting point, I decided that hand-editing the mapping files is the best approach. Also, the generated Java classes had the disadvantage that I couldn't really edit them because if I regenerated them I'd lose my changes, so even using HBM2Java was inconvenient and lead me to start hand-editing the Java classes as well.

So I gave Hibernate Synchronizer a shot recently because I read that it creates a class that you can edit all you want which extends a base class which contains the generated portion of the Hibernate domain objects. This was perfect until I realized something that I had done with some of my classes. I have web services that serialize some data from the domain objects, so I had created my own base classes for those objects which contained only the properties I wanted to serializable, which was basically only the basic Java types that can be serialized (e.g. String, Integer, etc), and not any of the relationship properties. This was to avoid having to worry about lazy relationships for two reasons: lazy relationships require Set which isn't interoperable and Axis tends to have problems with lazy relationships anyway. I had started creating a workaround for this issue in a past project and that was to copy the object graph to a nearly identical class structure that used arrays in place of Set's using reflection. This worked (and I was able to get Middlegen to generate it, too), but I never got the Set to array part finished (due to lazy exceptions). In the project I am working on here, I wanted to really keep it simple and only serialize the minimal stuff that I needed in my web service methods. Hence the base classes.

I took a closer look at Hibernate Synchronizer and discovered it was using Velocity scripts to generate the Java code. You can edit these scripts in the global configuration, or override them individually in your Eclipse projects. There was also a "template" feature which allowed for creation of additional files based on your own Velocity template. The general approach was do most of the work in "snippets" and then piece the snippets together in the template. So using a combination of overriding existing snippets and creating my own template, I was able to make the generated base classes extend yet another class which only contained the declaration and getters/setters for the primary key and the basic Java types. When editting the Velocity code, there was even code completion for the properties I could use. Very cool.

My only complaint was that for some reason I could not create a template at the project level. I had to create a template in the global configuration which also forced any new snippets to be at the global level as well. I got an error while trying to create a new template in the project and could only add a template after it had been created in the global config. I'd much prefer to have everything in the project so that it could be checked in to version control.

In any case, this will probably be the approach I would want to take in future work I do with Hibernate.