I have a base class called Address, which for the purposes of this example we can regard as abstract - I don't want to persist it in the db. It has all the expected methods such as getStreet, getCity, example. Now, I have some subclasses of this which I do want to persist - OrganisationAddress, CustomerAddress, etc. Using XDoclet, I would normally specify the necessary mapping above the getXXX method, e.g.:

...

/**
* @hibernate.property column="street" type="string" length="80"
*/
public String getStreet(){

...

But of course I don't actually have those methods now, they're all inherited from the parent class. So how do I specify the column mapping? Do I have to do something like the following? I.e., including the method but simply delegating to the parent:
...

/**
* @hibernate.property column="street" type="string" length="80"
*/
public String getStreet(){
return super.getStreet();
}


I hope not, as it takes a lot of the advantage of inheritance away.


...

I have part of my answer: the subclass inherits the properties anyway, so all I need to do is this:

/**
* @hibernate.class table="organisation_address"
*
*/
public class OrganisationAddress extends Address{

}

I must say I have had some difficulty fully understanding the Inheritance Mapping chapter of the reference on this point, and if anyone knows of any good documentation that would explain a bit more about table-per-concrete class, per hierarchy, etc., I would be eager to know about it. As it is, as I understand it simply doing what I have illustrated here does not use Hibernate's subclassing capabilities at all.

Consider trying 'Hibernate In Action'

You may look into testcases of xdoclet-2 plugin - there is an example

YOu shall map top level class as @hibernate.class , and the use @hibernate.subclass for classes sharing the same table, or @hibernate.joined-subclass for separate tables.

( See my signature for link )

OK, I've moved on now to using a table per class hierarchy strategy and have run into another issue. Various different classes (Customer, Organisation, etc.) have multiple addresses, which I'm implementing as Lists of Address objects. They could all just use vanilla Address objects, but I'm not able to think of a way of doing this using Hibernate, at least not with the XDoclet tags. The reason is that in the 'many' class, in this case Address, you need to specify the 'one' class in the many-to-one tag. Thus:

/**
* @hibernate.many-to-one column="address_owner_id" class="testing.Customer"
*/

I clearly can't have the same Address class work with multiple different 'parent' classes. The approach I've taken is to have multiple subclasses of Address, namely CustomerAddress, OrganisationAddress, etc., which are effectively empty in that they do not provide any different behaviour from the superclass but are really just a place to put the different Hibernate XDoclet tags. So in the base Address class, I have a getAddressOwner() method, which I override in each subclass thus (from the CustomerAddress:

package testing;

/**
@hibernate.subclass discriminator-value="Customer"
*/
public class CustomerAddress extends AbstractAddress{

/**
* @hibernate.many-to-one column="address_owner_id" class="testing.Customer"
*/
public AddressOwner getAddressOwner() {
return super.getAddressOwner();
}
}


Now I have to say that this business of creating 'empty' classes merely as places to put Hibernate tags strikes me as not quite right - I would have hoped Hibernate would not need to be so intrusive. This leads me to suppose that there must be a much better way of doing this, and any ideas are most welcome!

Well, you may have to think about directions of relation. Does address need to know that it belongs to certain entity? Do you like to navigate to this entity from adress?
You may have to create class hierarchy of "adressables" too...



Well, hibernate is intrusive - you still have to think about identites, collection types, (sometimes ) serializability, keys etc...

[quote="ko5tik"]Well, you may have to think about directions of relation. Does address need to know that it belongs to certain entity? Do you like to navigate to this entity from adress?
You may have to create class hierarchy of "adressables" too...[quote]

No, Address doesn't need to know that it belongs to a certain entity. Does this help me?

As regards Addressables, all the various 'parents' (Customer, Organisation, etc), implement an AddressOwner interface which I had hoped would allow me to be non-specific in my many-to-one tag (i.e., write the interface name as the class in the many-to-one tag. When I do that, though, Hibernate complains that no mapping exists for the class (which of course it doesn't, as I do not want an AddressOwner table).

I have the feeling I'm nearly there but just missing some vital piece of the jigsaw.

In this case you can try many-to-many mapping ( which uses another table ) or composite element ( but then your address is not an entity... )