All -
I have a parent object, which we'll call A.
Each A has exactly two child objects (no more, no fewer), of class B. We can call them B1 and B2. There is no ordering involved. In addition, B objects exist completely at the dependence of A objects -- there is never any need to have a B without its parent. In addition, B1 can be uniquely identified by A.id and one particular non-key field on A. B2 can also be uniquely identified in the same manner.
Overall, I don't think it makes sense for B objects to have their own id field that exists independently of A (that is, not foreign keyed back to A or somehow otherwise independent of A's identifier). But if this completely flies in the face of everything Hibernate is about, let me know.
There are certainly trade-offs between the two following basic strategies:
1. Use a <set> in the mapping and keep a Set of B objects in class A, like:
Code:
Set<B> bObjects;
Pros: One single reference to the collection in class A.
Cons: You have to check each time upon examining bObjects whether you're looking at B1 or B2.
2. Use two <one-to-one> elements in the mapping and keep a reference to B1 and a reference to B2 in class A, like:
Quote:
B bOne; B bTwo;
Pros: No need to check whether you're referring to B1 or B2.
Cons: Not really as elegant -- does not use Collections or Hibernate's support for them.
What I'm trying to do would, ideally, I think, look like this in the database:
Code:
A_TABLE
----------
id
non_key_field_one (perhaps foreign keyed to type table C)
non_key_field_two (perhaps foreign keyed to type table C)
(various other non-key fields)
B_TABLE
----------
a_id (foreign keyed to A_TABLE.id)
second_key_field (perhaps foreign keyed to type table C)
(various other non-key fields)
For B_TABLE, I'd like to have it have a composite key, made up of a_id and second_key_field. Then, B1 would be uniquely identified by the combination of A_TABLE.id and A_TABLE.non_key_field_one, and B2 would be uniquely identified by the combination of A_TABLE.id and A_TABLE.non_key_field_two. I think that's the easiest way to make it so that I can create SQL queries from scratch that join both tables -- the eventual goal here is to have Hibernate maintain the table definitions (and drop/recreate the tables when necessary), and then afterward, I'm going to be generating huge SQL queries outside of the context of Hibernate that I need to run on the tables Hibernate creates and maintains.
Any thoughts? Let me know if I'm barking up the wrong tree and I should instead be using a link table to link A objects and B objects (which would make the SQL queries I have to generate from scratch afterward a little more complicated) instead of the key structure I listed above. Thank you very much for any help!
Login
FAQ
Search