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.