Thinking about it, I guess I was looking at this from the user app angle too.
While on Cayenne end something like "IdString" or "StringId" will be more than
adequate, a concise term is needed to refer to it in an application.
Here is an example... In my Cayenne-based apps I am actively using "one-to-any"
relationships. This is a neat way to implement persistent "mixins" or
"aspects" - adding common persistence behavior to a set of unrelated persistent
classes (already adding lots of new terms here, right :)). E.g.:
create table content_version (ID, CONTENT_UUID, ...);
'content_version' table, as the name implies, stores some information about
"content". Content can be stored in any other table in the DB (can be dozens of
unrelated tables). CONTENT_UUID is a "logical" FK pointing to any of those
tables. It contains both the FK and the table name ("Artist:1"). So I am
looking for a naming convention that would set it apart from a regular FK (that
would be something like "CONTENT_ID").
Maybe borrow EOF terminology and call this a "Global ID"?
Andrus
On Nov 3, 2011, at 2:43 PM, Andrus Adamchik wrote:
>> Does this need an extra class? (I'm asking because the proposals above look
>> like class names, but I'm not sure whether that's intentional or accidental.)
>
> No separate class. This is a String. So this is more about the "concept name"
> used in various methods ("getUuid") and helper classes "UuidCoder".
>
> Andrus
>
>
> On Nov 3, 2011, at 1:03 PM, Durchholz, Joachim wrote:
>
>> Just my 2 brainstorming cents:
>>
>>> Folks, any suggestions for a short and clear term for what is a String
>>> representation of ObjectId?
>>>
>>> StringId
>>> SerializedId
>>> StringObjectId
>>
>> Does this need an extra class? (I'm asking because the proposals above look
>> like class names, but I'm not sure whether that's intentional or accidental.)
>> If not, I'd simply use String and refer to it as "ObjectId in String form"
>> (or, if the context makes it clear, just as "Object Id").
>> If yes, a look at that class or just its contracts might reveal more
>> semantics that would allow us to come up with something.
>>
>> Regards,
>> Jo
>>
>
>
