-----Original Message-----
From: Snively, Paul (SMCI) [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 18, 2003 12:16 PM
To: Les Hazlewood; [EMAIL PROTECTED]
Cc: Beckman, Sam; Venegas, Frank; Wu, Feng
Subject: RE: [Hibernate] Multiple Collections of Same Entity?Hi Les!The sets can definitely contain the same elements; in fact, "bars" is a proper subset of "otherBars."Thanks for the help!Paul-----Original Message-----
From: Les Hazlewood [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 18, 2003 4:39 AM
To: Snively, Paul (SMCI); [EMAIL PROTECTED]
Cc: Beckman, Sam; Venegas, Frank; Wu, Feng
Subject: RE: [Hibernate] Multiple Collections of Same Entity?Can a Bar in the "bars" set also be in the "otherBars" set? Or are the sets mutually exclusive?
Les
> -----Original Message-----
> From: Snively, Paul (SMCI) [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 16, 2003 7:18 PM
> To: [EMAIL PROTECTED]
> Cc: Beckman, Sam; Venegas, Frank; Wu, Feng
> Subject: [Hibernate] Multiple Collections of Same Entity?
>
>
> Folks,
>
> We're pondering an entity class that has two collections,
> both of which we'd like to contain instances of some other
> entity class:
>
> class Foo
> {
> Integer id;
> private Set bars; // Association to class Bar
> private Set otherBars; // Association to class Bar
> }
>
> From the documentation, it would seem that I would need two
> foreign key columns in Bar: one for each Set. First of all,
> is this correct, and secondly, are there any risks to this
> that I'm overlooking? I should add that I can assume that Bar
> is a lifecycle object of Foo, if that helps.
>
> Many thanks and best regards,
> Paul Snively
>
>
>
> **************************************************************
> *********
> This e-mail and any files transmitted with it are intended
> solely for the use of the addressee. This e-mail may
> contain confidential and/or legally privileged information.
> Any review, transmission, disclosure, copying, or any action
> taken or not taken, by other than the intended recipient, in
> reliance on the information, is prohibited. If you received
> this e-mail in error, notify the sender and delete this e-mail
> (and any accompanying material) from your computer and
> network. In addition, please be advised that 21st Century
> Insurance Group reserves the right to monitor, access and
> review all messages, data and images transmitted through
> our electronic mail system. By using our e-mail system, you
> consent to this monitoring.
> **************************************************************
> *********
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> hibernate-devel mailing list [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>
Title: Message
There
are three ways that I can see this problem being solved....
One is
to only have the "bars" set in class Foo. By pointing out that
"otherBars" is a proper subset, architecturally, this is probably the best
solution (I'll explain why below).
The
getOtherBars() method would be a manually-coded method coded such that it
returns a List based on restriction criteria for the "bars"
set.
e.g.
getOtherBars() {
List bars =
getBars();
List otherBars = new
java.util.ArrayList();
Iterator iter =
bars.iterator();
while (iter.hasNext())
{
Bar current =
(Bar)iter.next();
//psuedocode:
if (current meets my criteria)
{
otherBars.add(current);
}
//before returning otherBars,
you could cache it locally as a
//global class attribute and check
for null before doing the above logic:
//
// e.g. if (cachedOtherBars ==
null) do above logic
//
else return cachedOtherBars;
//
//just be aware that if the real
getBars() list is ever updated,
//you'd have to update your local
cache of "otherBars"
//you could determine this update
via a LifeCycle implementation.
return
otherBars;
}
The 2nd way would be to have two foreign keys in
your Bar table mapping, as you suggest. The first for the "bars" relation,
the second for the "otherBars" relation, which would be null if it wasn't part
of the "otherBars" set.
However, I don't like this second appraoch for two
reasons:
1) This encourages data replication and goes
against the principles of data model normalization, which I consider absolutely
critical to good design, manageability, and scalability of data
models.
2) This requires adjusting your datamodel of Bar
for the sole purpose of supporting Hibernate. The data model is core to
your business and shouldn't be adjusted for tools whenever
possible.
The
3rd way would be to have a hibernate query return the otherBars set for you as a
list based on a Hibernate query.
e.g.
List otherBars = dao.getOtherBars(myFooObject);
However, this isn't pure
OO "otherBars" list won't be part of the Foo object.
Choose
whatever appraoch meets your needs.
These
are just my opinions, so you should do whatever is necessary for your
company. I am a lead architect though, and architectural repercussions are
close to my heart, so I take more of the purist approach whenever
feasible. If pure OO principles must be in-tact, I would personally use
approach #1 in my company if there wasn't much of a performance cost, because it
gives me what I want and maintains OO. Otherwise, I'd just has happily
choose approach #3 if I can budge a little on OO. I could then let
Hibernate generate my Foo class for me without any modifications, and let
Hibernate worry about keeping "otherBars" up to date, since the query will
always return an up-to-date list. I am strongly against #2 as I feel the
datamodel should accurately represent the business data storage requirements of
the company as perfectly as possible. Adjusting for tools
(except for rare, specialized cases) is highly
undesirable.
Les
- [Hibernate] Multiple Collections of Same Entity? Snively, Paul (SMCI)
- RE: [Hibernate] Multiple Collections of Same Ent... Les Hazlewood
- RE: [Hibernate] Multiple Collections of Same Ent... Snively, Paul (SMCI)
- Les Hazlewood
