Re: hyper relationship howto?
Re: hyper relationship howto?
- Subject: Re: hyper relationship howto?
- From: Chuck Hill <email@hidden>
- Date: Tue, 22 May 2007 10:05:36 -0700
I'd go with inheritance. However, if you have multiple of these that
can lead to some fun finding base classes.
On May 21, 2007, at 2:35 PM, Florijan Stamenkovic wrote:
Hello YL,
Is this not a good example of where WO inheritance mapping could
come in handy? To be honest, I have never used inheritance till
now, never really needed it, but if I understand you correctly, the
problem you describe makes me think it that direction.
So, you could have all the entities that need address related
functionalities inherit from AssociationOwner, thereby instantly
having the toMany relationship towards Address in them. Hm, I
suppose it is not as easy as it sounds, and most likely single
table inheritance is not feasible, but still.
It is my impression that it would be an easier and also much more
EOF-friendly way.
As for an approach without inheritance, the way I see it, it would
be a lost cause. You just end up fighting one of the basic ideas of
relationships: that they know where they are pointing, statically.
Let them know where they are pointing (AssociationOwner), and they
will stay happy. The shortcoming would be that EOF would be the
only one holding the information needed to understand all this.
Where the basic idea of what you were describing would make it much
easier for other systems to also use the same data structure.
Also, regarding the actual situation you have described (things
relating to addresses), I am in the same situation (many entities
relating to addresses), and my solution is simply not to model the
relationship towards the address owner. Because I see addresses as
not-reusable data, i.e., there is a very small chance that two
address objects are identical and thereby need to be shared among
multiple address owners. So, I don't really need to know who is the
owner of a particular address. I need to know what is the address
of the owner. Anyway, in my scenario this is just two or three
entities (which are address owners), so it is not a big issue. If
it were more, or I needed the path from an Address towards it's
owner, I probably would try to solve it with inheritance, as
described above.
Best regards,
Flor
There are some practical reasons that one would hope some
relationships
among many entities can be treated as one:
businessUnit <<--->> address <<--->> person
may be ideally treated as
associationOwner (unit, person, ....) <-->> AddressAssociation <<--
> Address
By a proper implementation of AddressAssociation, address related
problems
can be treated in a uniform way across many entities. And the reverse
problems(from address to objects have something to do with it) can
be solved
equally easy.
Let's say AddressAssociation has the following attributes:
oid, oidAddress, oidOwner, ownerEntityName, startTime, endTime,
oidType,
status, notes
That way, the relationship's context can be recorded in a proper
way (in
reality, relationships are certainly not contextless). Also, an
obj can now
have many addresses as it actrually does, and the oidType can tell
the kind
of relationship (owner? rent? ...).
There are many things can be better handled by hyper-relationships.
Such relationships are not typical in IT practice but very common
in real
world. Without EOF or similar frameworks, doing things like this
can be too
costy, that's why WO:-). But...
In EOF, the callenge of such thing is mainly about to making
newAdressAssociation.setOwner(newOwner)
or newAdressAssociation.addObjectToBothSidesOfRelationshipWithKey
(newOwner,"owner")
work.
In theory, EOF's key assignment logic is good enough for such
generalized
case, It just not designed to look at the EOModel and realize hyper
relationships, and take care of attribute pair
(oidOwner,ownerEntityName).
I can be wrong since I'm not doing much on most new version of WO
Thanks for any ideas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden