Hi Budyanto,
Thanks for the link. I had a look at this page yesterday, and it didn't seem to quite address the problem, unfortunately. All the strategies require that the hibernate configuration know about the subclasses. The trick of what I'm trying to do is exactly the opposite: Hibernate should only know about the Node class, and all extensions to it are API sugar, and nothing whatsoever to do with storage (so, for example, the EmailAddress class is not permitted to add new information to be stored which couldn't have been represented by a Node class and a caller which understood the structure of an email address). For this reason, I explicitly don't want hibernate to know about the classes because that will limit the extensibility of the code.
I got around this yesterday evening by turning EmailAddress into a Decorator for the Node class instead, with a getter and setter for the MetadataNode. This is frustrating because although I get all of the functionality I wanted from the above strategy, and hibernate can deal with it, since we only use a pure Node class for storage and retrieval, I don't get the polymorphism that I wanted out of the object tree.
public class EmailAddress
{
private Node node;
public String getDomain()
{
node.getChild("domain");
}
}
Cheers,
Richard
|