I have to deal with a legacy data problem where I have two tables with similar data e.g.

t_cat_features and t_dog_features

each has the same data

height
weight
gender
breed


I created a hierarchy for cat and dog

public class Pet {
private String name;
private Integer ownerId;
private Features features;
...
}

and then;

public class Cat extends Pet {}
public class Dog extends Pet{}

and the Class Features for the attributes above.


Is there a way to map t_cat_features to Features when the parent is Cat and t_dog_features to Features when the parent is Dog?

At first I thought this was a case for the joined-subclass or subclass but that's not it.

If I define a <class> block for Features INSIDE Cat.hbm.xml and Dog.hbm.xml respectively, will I get the mapping I need?

I really don't want to have to create separate objects for CatFeatures and DogFeatures (this is a simplified explanation, there are several more tables involved that follow this pattern).

Any help will be appreciated.

Thanks

I found one solution but I still have to wonder if there is a better way.

What I've done is hand write the hibernate mapping files so that the parent and subclasses are all in the same file. Thus I have

cat.hbm.xml --> Cat, Features, etc
dog.hbm.xml --> Dog, Features, etc

I then set up a persistenceManager which initialized different instances of itself with each of these hibernate files. Then I can call back the appropriate Configuration from the PersistenceManager by keying each configuration to the parent class.

I had to abandon XDoclet to do this but that's OK.

It looks like Features is really just a Hibernate Set (or collection). Can you replace Features with Set? In that case you could easily have the Set grab matches from one feature table or the other. Alternately, you could make Features a set wrapper to preserve the Pet interface.

An interesting idea but I think I'm going to stick with the current solution for now.

I actually have two instances of Features in each Pet. One of them is drawn from a one table which is guaranteed to be a one-to-one relationship. The other does have to be mapped as a collection.

(This is the result of an old and awful data model, my goal is to create straightforward object model while the database gets remodeled. Then I can remap later.)

I'll definately keep this in mind for later, though.