This is tricky. Please read.

I have 2 classes:

Person which is actually mapped on a view in the database (PERSONS_VIEW)

and Patient which is mapped on a table (PATIENTS)

Patient extends Person.

I need to be able to make(and save) a Person instance first, then make a new Patient for that person and save it to the database. This should only save the data from the patient class, and not those from Person class(since it is a view).

I think of two variants (the first one seems to me clearer):

1. If I could somehow to tell the session to load the object with id 1(let's say) from the table PERSONS_VIEW (this is a Person), but load that data in a Patient object.

Like:
Patient patient = new Patient();
session.load(patient, Person.class, new Long(1));

//this should take the row with the id 1 form the coresponding table of the Person.class and fill the patient with that data (since Patient extends Person, it shouldn't be a problem - a patient is a person).

then I whould do:
session.save(patient); // and hope Hibernate is smart enough to not save in the view since no data was modified. Only data in the PATIENTS table was changed.


2. The other way to do this would be to be able to make the link between the two tables by myself, like:

//suppose the key of the joined subclass is "person_id"

I whould do:
Person p = (Person) session.load(Person.class, new Long(1));
Patient patient = new Patient();
patient.setPersonId(p.getId());
session.save(patient);



So, any idea?

Thanks,
Stefi.
Senior developer, Synygy Inc.

This situation looks too messy for Hibernate to handle the inheritance. One possible solution is the following:

interface Person;
interface Patient extends Person;
class ReadOnlyPersonBean implements Person; // Hibernate maps to PERSONS_VIEW
class PatientBean implements Patient; // Hibernate maps to PATIENTS

then ReadOnlyPersonBean and PatientBean could have a one-to-one relationship handled by Hibernate. PatientBean could delegate all the methods defined in Person to its ReadOnlyPersonBean field. You'd still have the feature that Patient isa Person, but it'd be handled by interfaces to hide the hairy underlying data structure.