Hibernate version: 1.2.0 Beta 3

I have a question about using Nested Subclass (One Table per class hierarchy) and collections

Here is my situation I have a three layers of derived classes (base, layer 1 and layer 2). How do I have collections of subclasses that are on layer one and will include layer 2 if I have to set a where claus for the discrimiator.

Example Hierchy
BaseShape
--SidedShape
----Square
----Triangle
--RoundShape
----Oval
----Circle

And here is my "parent" object

public class myShapes
{
public IList<RoundShape> RoundParts
public IList<Triangle> ThreeSidedParts
}

how can I populate RoundShapes properly using <subclass> with a discriminator? If I understand the 1.2.0 docs I have to set a discriminator in my where clause in the mapping file.. If I do that I can get (based on this example) Ovals or Circles but not both? or is NHibernate smart enough to know that if I use the discriminator for RoundShape it will pull both Ovals and Circles?

Thanks
Josh
PS: I hope that makes some symblance of since

AFAIK you have just hit a rather weak point of NH (somebody correct me if I am wrong).

If you map:


On initialization NH will not create any conditions to get just the rounded shapes, it will issue a condition to fetch all BaseShape-s.
This willl bring you a nice WrongClassException because it will get at some point a sided shape in the collection of rounded shapes and this will confuse it (or vice versa)

In order to solve this I have used ranges for all subclasses such as:


Then, for the mappings you can add a where="discriminator between 1 and 10" to the collection definition to get all SidedShape-s. This will work when the collection are lazy loaded. Unfortunately, with this workaround you will not be able to fetch join this association because the where attribute value will be added to the where clause, not to the join clause.

My best advice would be to use a single collection of all objects. If you will ever need filtering you can use shape.class = MyNamespace.Triangle
in HQL to get all triangles. Criteria does not offer a similar solution, but you can map the discriminator as a read-only column and filter by discriminator.

I don't know how much you have used NH so I will also state that in most scenarios (all but the later) NH will handle the discriminator properly.

I would really like to hear some other opinions for this case!

So should I consider using Joined-Subclasses then? I know those work in this kinda situation (or atleast they did in 1.0.3 on a test case I ran)..

What kind of performance hit would I take using <Joined-Subclass>
instead of <subclass> on a LARGE dataset (say 500,000 parent objects with 2 collections of 10 child objects each so 10,000,000 child objects)?
Or is that using the wrong "fix" for the stated problem?

Thanks again
Josh

I would not bet that joined subclass will not suffer from the same behavior. But if you have test cases for both initialization from lazy instance and fetch joining that I take it for granted.

As from the performance perspective it is not about the size it's just about the approach. That is retrieving collections with separate selects or with joins, all at a time or one at a time. I would say though that left joins may lower performance a bit (it depends also what database you are using) but not significantly. If you have the hierarchy on 7 tables you will always get 6 left joins but these can be optimized.

Unfortunately, I don't really think that there is a fix but just workarounds for this. Best approach (as in avoiding headaches) is to use a single collection holding all types. This is not a good OOD decision but than again you can't have them all :).

The main issue is that, at the moment, NH cannot add conditions on join clauses so anyhow you take it you will find some bumpy roads. I have used the discriminator approach but I now wish I would have used a single collection for all (because I didn't I can't really bet all my money on this solution either).

In conclusion, try using joined classes, make some tests using all kind of data with all types of fetching and than take the decision you find to suit you best. AND, don't forget to give us you feedback on the approach you take.