Thanks for your replies!
In response to Calin’s question:
The query to retrieve all x’s for and object a is done as follows,
SELECT * from T_X where parentID = a.oid
Because the parentID is unique in the database, the oids in table T_A and T_B are unique.
This is actually the main use for id generators which generate unique keys within the database and not just within a table. And hibernate supports them nicely. ;-)
In these cases it is not required to store the relationship (table name, which is a static relationship). This is why I do not get the picture with <any ..>).
Damon,
The relations do not have to be bidirectional.
Your code fragment describes the mechanism as it is done today (without hibernate) which is a bit messy as you pointed out correctly.
Interceptors:
When I use an Interceptor, I would have to load/delete,… the related objects myself, is that what you mean?
eg. for load it could look something like this:
Code:
public boolean onLoad (….)
if (object instanceof A) {
// read x’
Set x = xDAO.getByParentID(a.getID());
// initialize x’s in a
a.setX(x);
return true;
}
if (object instanceof B) {
..
}
}
...
I will also look into the custom SQL, thanks for the tip.
However, with interceptor or custom SQL, I actually have to implement the relational logic "myself".
Isn’t that what hibernate should do for me? Or is this just an exotic ORM problem?
I doubt it.
In the object oriented world, we like to reuse our classes; in the relational world, we try to avoid tables with the same structure (normalization). But hibernate seems to force the user into the direction:
Class A needs a table T_A_X for his collection members x
Class B needs a table T_B_X for his collection members x
even though the elements (x's) are the same, i.e. both tables are identical.
I am aware, that sometimes the database must be denormalized and two or more separate tables make sense (ex. horizontal split for performance). But this is not always the case!
Urs