RE: Composite keys

Hi again,

As usual, the simple act of typing and sending that to the list seems to
have straightened things up in my mind, and I've tried out overriding
accessors to set the relevant keys which does what I want and is pretty
straightforward.

That said, if anyone can point to any detailed composite key documentation
I'd still love to see it.

(Also, on posting to [email protected], I got the message bounced twice from
[email protected] and [email protected] - apparently
these lists no longer exist, so if anyone at Omni is reading, this forward
might be out of date. I'll forward you the bounces if you're interested.)

Bests
Igor.

-----Original Message-----
From: Clark, Igor 
Sent: 04 November 2003 15:10
To: '[email protected]'
Subject: Composite keys


Hi folks,

I haven't managed to find any really relevant sources of documentation on
the finer points of using composite keys with EOModels in either the WO
developer docs or searching through any of the lists, so I'd appreciate any
pointers or tips you might be able to give.

I'm clear on how to use EODatabaseContext delegates in the circumstance
where the keys need to be generated; where I'm coming up against questions
is the conceptual side in a case where the keys have already been created
and the relationships need to be managed.

I'm dealing with a legacy system which has the relationship A -->> B where
B.idA is a foreign key into A, and B's primary key is a composite of idB and
idA. The keys are created elsewhere and read into the application either as
batches or through a form (I can't change this, otherwise we'd have unique
single-column primary keys as quick as you like), and they need to be class
properties because they are meaningful to users.

So far so OK, but when I model this relationship, create A aObj and B bObj
and try to bObj.setA(aObj), bObj.idA is only set to the value of aObj.idA if
B.idA is not specified as part of the primary key; it is not set if it *is*
part of the primary key. This makes sense because if it is set as part of
the primary key, then my databaseContextNewPrimaryKey delegate method is
called and I can go work through all the EOEntity / EORelationship /
EOAttribute stuff to find the appropriate target attributes and set them in
the relevant places, but this is getting somewhat involved. Alternatively I
could override my _B.setIdA method (generation gap pattern) in B.setIdA and
set the relevant keys by hand, but this seems to be missing the point of EOF
a bit in that I can't just takeValueForKey or even
addObjectToBothSidesOfRelationshipWithKey and have it do what I expect.

Am I missing something basic? It just seems a bit mad to go to all this
length to tell EOF what the key values should be - is it just because EOF's
design doesn't really like composite keys? 

Thanks for reading,
Igor.
_______________________________________________
EOF mailing list
[email protected]
http://www.omnigroup.com/mailman/listinfo/eof