Hope the title is clear, just tossed in keywords for easy searching.
I love the hbm2java utility and I'm trying to find a way to make it permanently useful. I'd like to use it to generate business class skeletons, which can then be customized with additional functionality, without losing the ability to regenerate if the mapping file changes (if schema changes for instance).
My original thought was to simply subclass the generated classes to add any additional behavior that the generator can't generate from the mapping. Date validation for instance, or extra methods. It seemed like the perfect approach. The subclasses would inherit all the base functionality, and would only need to override or add any methods needed to customize the generated code. If the generated files needed to be regenerated in response to mapping or db changes, then the custom classes would automatically inherit from the new generated classes. This way we could take advantage of the code generator to simplify maintenance, and also take advantage of improvements in the code generation toolset in the future.
In practice, this approach doesn't seem to work, as the Session.saveOrUpdate() method will complain that no persistor is defined for the subclass of the generated class. I had hoped that it would be content with the fact that the class being passed 'is a' mapped class, but apparently it's quite strict and uses the exact subclass, even if the subclass hasn't been mapped. I understand why this should be, since hibernate supports persisting inheritance hierarchies. But it also seems like it would be possible to persist using a superclass if this was explicitly requested, or if the subclass mapping couldn't be found.
Will persistence by interface be supported in the future? Is there a better way to achieve my goal of regenerability + customizability. My findings so far seem to show that code generation is only useful as a shortcut for initial development, not for maintenance, which would be an unfortunate limitation of a tool with fantastic potential.
In the same vein, it would be nice if queries could be customized to return parent types. For instance, if I had a mapped Customer class, and a CustomCustomer subclass, it would be nice if I could tell the query to use the Customer mapping, but to return a CustomCustomer instance, since it is guaranteed to have all the necessary setters and getters. This would mean the query would need the ability to accept both a mapped class type, and an output class type.
Is this a philosophy that hibernate would encourage? (customization through subclassing), or is a different approach to customization preferred. Would appreciate any direction to articles or topics covering this theme. (I searched the forum without finding anything relevant, is no one else interested in 'regenerable' code?)
Respectfully,
Thom
|