i am also looking for a solution to the same problem. it's a not uncommon to create sub-class of persistent class that represents extra business logic which has nothing to do with persistence. and it's not reasonable to configure each sub-class (effectively as an empty sub-class) in hibernate, because sometimes you don't even know what sub-classes can be created. they can be created by your users if you are selling a software product/API.
to solve your first problem of saving a sub-class instance, you can use
session.save(<base class name>, <sub class instance>)
what i am struggling with is the 2nd problem to have load/query instantiate a sub-class instance. i tried the interceptor approach and it doesn't appear to work.
can someone enlighten me on how to solve it? i played with extending the load API on Session a little bit. but i would like to know if there is already an easy way out, especially for the query result.
thanks.
scornflake wrote:
HI all,
I'm attempting to persist a class heirarchy without really wanting to persist the heriarchy.... that is, during processing of incoming requests, I may be using subclasses, e.g: SpecialFoo, which inherits from Foo.
Foo itself has a mapping file. SpecialFoo does not.
Upon attempting to persist a SpecialFoo, I get "No persister for: SpecialFoo". Which is reasonable I suppose, since I have not defined a mapping for this class (but it does inherit from the concrete Foo).
So my Q is this: Is there a way in hibernate to:
1) Write derived classes to the DB (for example, a SpecialFoo), using it's base class mapped properties
2) Read object just using the base mapping file.
With (2) above, I realize that upon reading/loading objects I'd simply be instantiating Foo objects for every row in the table. This is fine. I just need to understand if it's possible to persist (save) derived classes without doing the "full on" descriminator style mapping (which is my simple case, would introduce descriminator values where in reality there are none - the descrimination occurs only in the objects during processing, not in the data they end up holding).
Regards,
Neil Clayton