Hi developers

I wonder if anyone could be kind enough to answer if there is any plan to support table per subclass mapping with a discriminator column? In our application, the performance impact of all the extra joins for a polymorphic select of a simple row is really significant.

Thanks all as always for the good work.

N.

I don't believe so, it makes for a really hard problems down the road.
Is there a reason you can use a normal discriminator scheme/

Hi Ayende

Here is one example out of many where it is a big problem for us. A base class (Task) exists in the system; inheriting it are SendMessageTask, RequestApprovalsTask, DistributeSoftwarePackageTask, and twenty others. Tasks have some common base attributes, as well as a large number of other defining characteristics.

A user or automated system logs in, and he needs to see what next task he/she/it should perform. The polymorphic query results in 25 joins in order to see what type of task is actually returned. Very expensive - in the automated system (the "it" case :) ) we are running around 200 of these queries per second, and it's absolutely killer (not in the positive sense!).

The other part of the problem is if I have two classes inheriting Task that override virtual methods and behave differently, but don't add any extra properties - what's really crazy is that you then have to create empty tables with just primary keys, so Hibernate can join to find what type it should be! Ode for a discriminator column.

This is what I believe the Hib3 feature of table-per-subclass with discriminator (called subclass with join sub element) was designed to alleviate?

Thanks again all for the good work.

N.

That is something that Sergey should answer, I think.
A better way to structure this might be with a many-to-any assoication, although I am not sure about the implications of that.

Sergey, do you have any ideas on how we can better refactor this?

You've touched on something interesting here - a problem which many of us face I think.

Let me address this in two parts:

1. How to make the current table-per-subclass model more manageable:
- use views to create the artificial "tables" of primary keys; for example, we have an interface (much like your Task) which is implemented by many mapped classes; we have a view which aggregates all the primary keys (and other properties of the interface) using the UNION keyword.

2. The "any" association type
- try the "any" association type; the shortcoming of this is that you can not do "polymorphic" joins or queries on properties mapped using "any". So for example, if you have a table for Assignments of your Tasks, with a column for taskID, and taskType (required by "any" mapping), it will load and instantiate the appropriate Task, but you can not search your Assignments by Task SUBproperties, as this would require multiple joins which you're trying to avoid (and which is not implemented).

Regardless of the limitations of this, I believe the "any" mapping is what you're looking for when you mention "foreign key type". Have a look here for more:

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

Any feedback or confirmation from developers would be greatly appreciated.

Thanks,

-Sasha Borodin