You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2011/11/03 07:46:11 UTC
Fwd: [jira] [Created] (CAY-1639) cayenne-lifecycle: don't call String representation of ObjectId a UUID
Folks, any suggestions for a short and clear term for what is a String representation of ObjectId?
StringId
SerializedId
StringObjectId
?
Andrus
Begin forwarded message:
> From: "Andrus Adamchik (Created) (JIRA)" <ji...@apache.org>
> Date: November 3, 2011 9:43:33 AM GMT+03:00
> To: andrus@objectstyle.org
> Subject: [jira] [Created] (CAY-1639) cayenne-lifecycle: don't call String representation of ObjectId a UUID
>
> cayenne-lifecycle: don't call String representation of ObjectId a UUID
> ----------------------------------------------------------------------
>
> Key: CAY-1639
> URL: https://issues.apache.org/jira/browse/CAY-1639
> Project: Cayenne
> Issue Type: Improvement
> Components: Lifecycle Extensions
> Reporter: Andrus Adamchik
> Assignee: Andrus Adamchik
> Fix For: 3.1M4
>
>
> "UUID" term is used very loosely in cayenne-lifecycle. Per http://en.wikipedia.org/wiki/Universally_unique_identifier UUID is a 16 byte number. Our "UUID" is a String like "Artist:1"... Need to call it something else and renamed the corresponding lifecycle classes before it made to a GA release. Not yet sure what a good short term might be, but essentially we are talking about an ObjectId serialized to String.
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>
Re: [jira] [Created] (CAY-1639) cayenne-lifecycle: don't call String
representation of ObjectId a UUID
Posted by Michael Gentry <mg...@masslight.net>.
Cayenne ID? Persistence ID?
On Thu, Nov 3, 2011 at 2:46 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> Folks, any suggestions for a short and clear term for what is a String representation of ObjectId?
>
> StringId
> SerializedId
> StringObjectId
>
> ?
>
> Andrus
>
> Begin forwarded message:
>> From: "Andrus Adamchik (Created) (JIRA)" <ji...@apache.org>
>> Date: November 3, 2011 9:43:33 AM GMT+03:00
>> To: andrus@objectstyle.org
>> Subject: [jira] [Created] (CAY-1639) cayenne-lifecycle: don't call String representation of ObjectId a UUID
>>
>> cayenne-lifecycle: don't call String representation of ObjectId a UUID
>> ----------------------------------------------------------------------
>>
>> Key: CAY-1639
>> URL: https://issues.apache.org/jira/browse/CAY-1639
>> Project: Cayenne
>> Issue Type: Improvement
>> Components: Lifecycle Extensions
>> Reporter: Andrus Adamchik
>> Assignee: Andrus Adamchik
>> Fix For: 3.1M4
>>
>>
>> "UUID" term is used very loosely in cayenne-lifecycle. Per http://en.wikipedia.org/wiki/Universally_unique_identifier UUID is a 16 byte number. Our "UUID" is a String like "Artist:1"... Need to call it something else and renamed the corresponding lifecycle classes before it made to a GA release. Not yet sure what a good short term might be, but essentially we are talking about an ObjectId serialized to String.
>>
>> --
>> This message is automatically generated by JIRA.
>> If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>>
>>
>
>
Re: [jira] [Created] (CAY-1639) cayenne-lifecycle: don't call String representation of ObjectId a UUID
Posted by Andrus Adamchik <an...@objectstyle.org>.
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
>>
>
>
RE: [jira] [Created] (CAY-1639) cayenne-lifecycle: don't call String representation of ObjectId a UUID
Posted by "Durchholz, Joachim" <Jo...@hennig-fahrzeugteile.de>.
> No separate class. This is a String. So this is more about the "concept name" used in various methods ("getUuid") and helper classes "UuidCoder".
In that case, my proposal is indeed this one:
> I'd [...] refer to it as "ObjectId in String form" (or, if the context makes it clear, just as "Object Id").
Possibly as "serialized ObjectId" if that String form is intended for serialization.
I wouldn't create new terminology just for naming different representations of the same semantics.
Just my 5 cents :-)
Regards,
Jo
Re: [jira] [Created] (CAY-1639) cayenne-lifecycle: don't call String representation of ObjectId a UUID
Posted by Andrus Adamchik <an...@objectstyle.org>.
> 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
>
RE: [jira] [Created] (CAY-1639) cayenne-lifecycle: don't call String representation of ObjectId a UUID
Posted by "Durchholz, Joachim" <Jo...@hennig-fahrzeugteile.de>.
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