I have a system where a number of different classes (Organisation, Customer, etc), all have multiple Addresses. My original design for this involved having subclasses of Address, such as OrganisationAddress, CustomerAddress, etc., with one-to-many mappings. Each subclass would have the a field consisting of the 'parent' type (Customer, Organisation), with appropriate getter/setters. The subclasses were mapped using the table-per-class-hierarchy strategy.

Now, it struck me that this was perhaps redundant as there is no differentiation between the subclasses other than what their 'parent' is. So, I came up with the idea of an AddressOwner interface, to be implemented by Customer, Organisation, etc - all the classes which 'own' a number of addresses. These classes are all subclasses of a BaseBusinessObject with getId and setId methods, all using Longs for ids. So, why could I not simply use Address objects and have an AddressOwner object as a field of the Address, with getAddressOwner/setAddressOwner methods?

The fly in the ointment with this approach is when I come to do the mappings for the Address class. I have to specify a class for the many-to-one mapping for the AddressOwner field, but of course, AddressOwner is an interface, not a concrete class. I want Hibernate to use the concrete implementation (Customer, Organisation).

Where have I gone wrong in my thinking?

You can simply specify the interface in your mapping files.



If you use HibernateTools you can map an interfaces like this:


Hope this helps.
[/code]

[quote="Dencel"]You can simply specify the interface in your mapping files.



That's what I tried to do. When I do a build, though, I get the following error:

"An association from the table address refers to an unmapped class: mypackage.AddressOwner"

I clearly have to specify a class which has a mapping. But I don't want to have a mapping for the IAddressOwner, because I don't want to have an AddressOwner table, that would defeat the object. As I understand it, as I want my various implementations of the AddressOwner interface (Customer, Organisation) to have their own tables, and therefore I am using the table-per-concrete-class strategy, I should be getting implicit polymorphism, shouldn't I?

Map the interface. In my previous post there is an example how to do this.

I don't have Hibernate Tools. How would what you have shown look in a normal mapping file?

Sorry, I should be more accurate. This mapping doesn't require HibernateTools.
This mapping will work in Hibernate. Hibernatetools looks at the extra meta-attributes, but they are ignored by Hibernate.
In the example BBO is an interface.

OK, thanks. I'm using XDoclet for my Hibernate tagging, so I'm assuming that there is something I can put at the head of the class which will generate the mapping you mention. I would normally put something like this, specifying a table:

/**
* @hibernate.class table="customer"
*
*/

But does it make sense to do simply this, as I don't want a table?

/**
* @hibernate.class
*
*/

I don't use XDoclet. It's probably documented in their documentation. I rather start from mapping file instead of java files when programming with hibernate. But that is mho.
The workings of XDoclet is off topic here.

OK, I'll ask the question differently. What sense does a class mapping without a table attribute make? I'm trying to understand what it is doing.

Hi,


I use xdoclet and mapped the interface as a normal concrete class, although, if you use schema-export, it will create the table for the interface that hibernate will never use (i suppose, running through tests, nothing was inserted)

Best regards,
thiago souza