Craig is right - DbAttribute names are natural keys for a generic
implementation of the ObjectId.
BTW, Holger, are you looking at this issue that Laszlo reported? I guess
we need to open a bug report on SF.
Andrus
> Well, it can't be an ObjAttribute name because there's no guarantee the
> PK will be available as an ObjAttribute. In fact, we generally advise
> not to. +1 for figuring it out from the mapping, at least for the case
> where there's only one attribute. Multiple attribute pk's would be
> difficult without the current Map, in which case we need keys to
> identify which attributes each value maps to.... arrghh.
>
> Craig
>
> On Sun, 11 May 2003, Holger [iso-8859-1] Hoffstätte wrote:
>
>>
>> I'm trying to reproduce Laszlo Spoor's flattened relationship bug and
>> just realized that ObjectId takes the name of the DbAttribute instead
>> of the name of the ObjAttribute. This is extremely surprising! I don't
>> know why I haven't noticed this before, but shouldn't this be regarded
>> as a bug? I mean when I have to know the name of the physical
>> attribute when constructing an ObjectId, it violates the Obj/Db* layer
>> separation. Maybe even the name of the attribute should be completely
>> taken out, after all we already have the class/ObjEntity in question
>> and can find the name of the PK(s) from the mapping.
>> Thoughts?
>>
>> Holger
>>
>
> 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 : Mon May 12 2003 - 13:39:28 EDT