> Craig,
>
> I am copying this to the list, so that others can participate too. (Just
> like subject says, this is about adding flattened relationships)
>
> At 06:45 PM 10/16/2002 +1300, Craig Miskell wrote:
> >My current thinking is that it's the ObjRelationship's responsibility to
> >a) know it it is a flattened relationship, and
>
> Yes. I think we should make it explicit by adding a corresponding boolean
> method.
Cool - I can start with that :-)
> >b) handle adding/removing at the object level (creating intermediate
> >objects etc).
> >c) probably vetting at some stage that the intermediate objects only
> >contain foreign keys (or that the other fields are optional)
> >Then all we'd need is the relationship parsing code (path traversal I
> >think) to recognize a flattened relationship and put in the extra join.
>
> The idea was closer to (c): we wanted to make it cooler than EOF - there
> will be no intermediate objects. The idea was to maintain m-to-m
> relationships at the object level, and create/change rows in a join table
> at the SQL level, avoiding creating a "join object". BTW, this was one of
> the main reasons for the whole Db*/Obj* separation in the map. This is the
> biggest piece to implement, since it affects query translators and the
> whole object graph management. I guess we can start by doing read-only
> support for such things, and then move to more complex updateable behavior.
>
> It may also be simpler than I think as far as object graph concerned - I
> guess we may treat "m-to-m" relationship as a simple to-many at the object
> graph level. Of course the underlying wiring would still need to be aware
> of the real structure.
>
> Andrus
That does sound cool. If the user needs access to an intermediate
object/table, then flattened isn't the way to go (I think we did that once
in EOF, but it was a bad idea :-)).
I am tending towards your second thought, that as far as the object graph
is concerned, it's just a toMany relationship at both ends. The only
thing that would need mod's adding/removing objects (CayenneDataObject,
but we can spin the details out to some other place, possibly
ObjRelationship?), and the creating appropriate joins in the query
translators.
Just for convenience, I propose we use the following schema for
discussing:
Person <-> Phone number
A given person may be possibly available at more than one number (mobile,
work, home), but each number may also reach more than one person (esp.
home/work).
To get read support, we'd mod QueryHelper.selectRelationshipObjects and
create a OBJ_PATH expression like toPerson=<source object>, then let the
query translator figure out it needs to join. The path traversal would
notice that the ObjRelationship is flattened, and generate a join across
the DbRelationships that make it up.
Write support (add/remove) would be specialised for flattened
relationships, and just create/delete rows in between.
The more I think about it, the more easy it seems. Which rings alarm
bells, and makes me wonder what I'm missing.
What do you think?
Craig Miskell
Programmer, Black Albatross, Otago University, New Zealand
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d- s+:- a-->? C++++(++)$ ULXH+++$>++++ P+>++++ L++$>++++$ E--- W+++$
N+ K? w--- !O M-- V? PS--- PE Y t++ 5 X+++ R-- tv+ b+>+++ DI++++ D+ G+ e++
h--- r+++ y+++
------END GEEK CODE BLOCK------
This archive was generated by hypermail 2.0.0 : Wed Oct 16 2002 - 21:42:52 EDT