How can I use an Interface for a Component?
I cant see a discriminator between the Component tags?
Is there an alternative way to do this

No Inheritance for Components. Use a full entity.

The problem is how I map the component to a part of the same table. Maybe I'l explain the situation.

I have an 'Instruction' entity that has a 'state' field.
The 'Instruction is mapped to a table called 'INSTRUCTION' that has a field called 'state'.

The thig is I want to implement the state pattern in my logic, so I want the state field to be of a Istate interface type and I want Hibernate to load the correct concrete class based on a text field called state in the INSTRUCTION table.

Did I make my self clear ?

Yes, pretty clear. I don't think thats possible, though.

I have the same problem. I would like to use the State Pattern, in which each state is represented by a concrete subclass. My legacy database has a state column that holds integers representing the state. It would be very easy and elegant to implement a full State Pattern in Java and map it to the database like this:



Unfortunately, Hibernate does not (yet) support inheritance in the component tag. Hence I have 2 questions:

1) Can this feature be added to a future feature list? I think the prevalence of this type of State Pattern alone would warrent it, and it seems consistent with the overall design and use of the framework.

2) Does anyone have any recommendations about how to implement this without this feature? I have thought of several possibilities, all of them bad:

I thought of doing a one-to-one mapping of my AccountState class to the Account table, but I assume this will fail during inserts because, since they both point to the same table, the new AccountId will already be present when we try to insert the AccountState number (though I haven't tried this).

Another idea is to push the inheritance logic up into the domain model. That is, the stateId could be a simple integer mapped to the STATE column (which Hibernate can easily handle), and my setter for Account.stateId will handle the logic of finding and instantiating the correct subtype of AccountState. That's letting a lot of ugly persistence logic bleed into the domain model, but it should work.

A final possibility is to try to bastardize the UserType interface to treat the state as an immutable value type. That is, I could make an AccountStateUserType that is saved in the ACCOUNT table, and it uses the subtype to get the value and create the correct subclass when re-instantiating. Unfortunately, I don't see how this can work as the UserType method returnedClass() doesn't have any way to access the state number, which is needed to determine which subclass should be instantiated.

Am I missing something?

Thanks!
James

I also have the same problem. Essentially I want to do the same thing as James. I have a legacy table of account holders which, as well as basic account details, also holds payment information. This can be either credit card or direct debit (bank account) details. So I want my Account domain class to have a 'paymentDetail' component property, which will either be a CardPaymentDetail or DirectDebitPaymentDetail, depending on which data is present.

I think I'm going to have to map the fields as simple properties and do the appropriate PaymentDetail object creation within my domain class. It would be much cleaner if <component> supported nested <subclass>.

Al.