Is there anything wrong about having two Java classes mapped to the same table?

I have an entity (e.g. course) that has a number of related sub entities (e.g. attendees, class times etc) but I don't want to include these sub entities as properties in the main entity class structure.

To get around this I'm using the following class hierarchy...



The class 'AbstractCourse' contains all the properties associated with a school class.

The class 'Course' is a sub class of 'AbstractCourse'. I have a normal set of create, read and update operations active against this class.

The class 'CoursePlusBookings' is a class that includes collections of related entities like 'Attendees'. I use the 'delete' method on this class
as the Hibernate mapping includes a'cascade delete' element. That way when I delete a 'CoursePlusBookings'instance the related 'Attendee' instances are deleted as well.

Is this a sound way to manage persistence using Hibernate?

The name CoursePlusBooking seems to hint to a design flaw. But that is unrelated to Hibernate.

Hibernate wise such an approach is fine. Just make sure to make the proper inheritance mapping.

Jens

What do you mean by inheritance mapping?

http://www.hibernate.org/hib_docs/refer ... tance.html

... I don't see how mapping inheritance relates to this problem.

The core question is about having a main entity that maps to a table that has subordinate sub entities but for normal usage I don't want the sub entities included in the main class.

What do you mean by "sub entities included in the main class"?

From the previous posts you have 3 classes that build a inheritance tree. As far as I understand it, you want at least two of them mapped to a single table. The way to do this is called inheritance mapping in the hibernate universum.

Jens

OK, so this looks kind of like "table per class hierarchy" (http://www.hibernate.org/hib_docs/refer ... leperclass).

But what should the discriminator value be? In this scenario, every record could be mapped by either class (that sounds a bit odd, but see the scenario at the end). And will it cause problems if you have two objects , one from each class, that map to the same row?

Another way to look at this is:

Course
|---- CoursePlusOptionalAssociations

CoursePlusOptionalAssociations only exists to add associations to Course. And then the question becomes:

How do I map a subclass which has no properties (and therefore needs no table) but does need to represent one end of an association?

Why would we want to do this? Let's imagine that Course is part of a framework or subdomain that sits underneath other parts of our domain model. We might have dozens of higher level modules that might want to associate with Course - billing, enrolments, timetabling etc. We might even want to access that same Course domain model from an entirely different application.

In this scenario, it's clearly inappropriate for the Course module to include association mappings to all the higher level modules. It's much better for the higher level modules to extend or decorate Course to include their own specific properties and associations, so you'd have BillingCourse, EnrolmentsCourse etc.

So what should the mapping for BillingCourse look like? It's equally inappropriate for the BillingCourse mapping to repeat all the mapping details that we already have in the Course mapping file - not DRY and a breach of encapsulation. If BillingCourse has persistable properties, we create a BillingCourse table and use "table per concrete class" using the nice <subclass extends=""...> mapping.

But what if BillingCourse has no persistable properties and extends Course only to provide an endpoint for associations to other billing objects? AFAIK, our options are:

1. Create a BillingCourse table anyway, purely to hang a subclass mapping on.
2. Have BillingCourse map back to the Course table. Just a very simple mapping with just the PK would do for this purpose.
3. Define BillingCourse as a <subclass> of Course with a discriminator that will include every row. Probably means that we have to use a different session factory for each high-level module.


If we choose the second option, this scenario starts to look very like the OP's "two classes mapping to one table" scenario.

Ok, I think I now get where you are heading.

1. What you are looking for is not only to map two classes to the same table, but two classes two one row. I don't think this is (or should be) possible. Hibernate wouldn't be able to tell which class to create from the table.

2. Try what I personally refer to as Role-pattern. I don't know if it has some official name. The purpose of that pattern is to seperate different usages of a class from the class itself.

It would look something like this:

interface Course{
public CourseRole getRole(Class<?>)
};

abstract class CourseRole extends Course{
Course course // use delegation to this in order to implement the course Interface
}


class CourseImpl implements Course{
private Map<Class<?>,CourseRole> courseRole
}

class BookableCourse extends CourseRole;

class BillableCourse extends CourseRole;

Go ahead and map this to Hibernate in Order to keep the Course Interface and it's implementation independent of all the references to the Course.

HTH
Jens

Jens,

So what would the mapping look like?

Jaime

I think this will work - the only issue will be if your try to load a single row as both classes at the same time in the same session, in which case you'll need to evict the old one from the session before you can load the new one.

The idea was that one version represented a kind of "light" version of the object. I seem to remember this approach being recommended as a workaround for Hibernate not supporting "lazy properties". I don't remember if there were any issues with this approach though (other than the already mentioned one about not being able to load instances of both classes for the same row at the same time).

Doesn't Hibernate now support lazy properties though? Maybe that approach might work better for you?

In the example of davout_uk AbstractCourse should be annotated with @MappedSuperclass and it should work fine without any additional inheritance annotations.

What didn't work for me is to eliminate the AbstractCourse class, just use Course and extend from it. In that case Hibernate complains that there is a missing discriminator type column. IMO it should work as with the abstract class.

Cheers,
Yuri

I was looking for something similar and found another solution. I have a class with a limited number of attributes for listing entries on a web page. I have another class that extends the first one to provide full detail when the user clicks on one of the entries.

To make this work I had to specify the "entity-name" attribute on the "class" tag. Otherwise Hibernate would load each row twice, once for each mapped class. I used the the same value as the "name" attribute for the "entity-name" attribute.

Something similar is mentionned in the manual at http://www.hibernate.org/hib_docs/refer ... entityname,
but in the manual it is the same class that is mapped twice using 2 distinct entity names.

Nick

Deleted accidental double post.

Well, this definitely looks like a compound set of classes going to one table, as opposed to inheritance. Mapping such a relationship is quite easy with Hibernate, especially if you're using JPA. I map a relationship like this one in a free Hibernate3 tutorial on my website:



It's rather simple, Just make one class the primary entity, and the second, an embeddable entity. Here's the code for the embedded entity:

http://jpa.ezhibernate.com/Javacode/learn.jsp?tutorial=14mappingtwoclassestoonedatabasetablejpahibernate




And here's the core entity using the embedded class:



I'ts just that easy!

http://jpa.ezhibernate.com/Javacode/learn.jsp?tutorial=14mappingtwoclassestoonedatabasetablejpahibernate

Cameron,

This is a nice explanation of embedded components, but differs from the OP's and my scenarios in two important ways:

1. You split the fields of table thing across classes Thing and ThingDetail. In our scenarios, all the fields of the table would be on class Thing. ThingDetail would have no scalar properties.

2. Your ThingDetail has no associations with other entities. Table thing has no foreign keys. In our scenarios, ThingDetail would have collection-valued properties implementing associations to other entities.

I'd love to know if embedded components can support this scenario.

Jaime Metcher