RE: Non-integer primary keys
RE: Non-integer primary keys
- Subject: RE: Non-integer primary keys
- From: "Clark, Igor" <email@hidden>
- Date: Tue, 3 Aug 2004 10:18:26 +0100
Hi,
If you make the primary key a 24-byte NSData field and the column in the
associated table a binary value (RAW in Oracle) then EOF converts its
24-byte EOTemporaryGlobalID values into EOKeyGlobalID values and stores them
in the column. According to the class description for their superclass
EOGlobalID,
"An EOGlobalID is a compact, universal, identifier for a persistent object.
This forms the basis for uniquing in the Enterprise Objects Framework. An
EOGlobalID uniquely identifies the same object or record both between
EOEditingContexts in a single application, and in multiple applications (as
in distributed systems)."
[
http://developer.apple.com/documentation/WebObjects/Reference/API5.2/index.h
tml ]
I've always understood this to mean that the keys thus generated are
universally unique.
It's an *extremely* simple method of dealing with primary keys: simply make
the field and the column, and EOF manages all key generation for you.
There's no round trip to the database to get new keys, and you don't need to
implement a primary key generation mechanism. A downside (there may of
course be others I haven't considered) is that as all key fields are
populated with values such as
'00009C47489B00000BB3A900000000FD2E06D97EB30ABC5F' it becomes, shall we say,
slightly unwieldy to read the database from outside your WebObjects/EOF
application, and for simple purposes impossible to write new records from
outside it without implementing your own analogous key generation mechanism.
This seems only to be an issue if your database needs to be accessed by
other non-EOF processes.
Hope this is of some interest,
Igor
-----Original Message-----
From: Dov Rosenberg [mailto:email@hidden]
Sent: 03 August 2004 02:46
To: Steve Sharman; Art Isbell
Cc: WebObjects (Group)
Subject: Re: Non-integer primary keys
We use character based primary keys in our application. We create our own
GUID by combining a portion of the server IP address with a guid generated
by java.rmi.server.UID class. This makes all of our primary keys in all of
our tables unique. Since they are guids unique across machines it makes it
much easier to replicate data.
HTH
Dov Rosenberg
Conviveon Corporation
http://www.conviveon.com
On 8/2/04 7:28 PM, "Steve Sharman" <email@hidden> wrote:
> Thanks for the reference Art - that's what I was looking for. And
> you're right - what I'm thinking about doesn't make any sense from a
> WebObjects viewpoint - I was mulling over various models for how a
> distributed or mobile WO application might work from an object
> synchronisation perspective.
>
> What I was thinking was that if I could ensure that each separate
> application (each with it's own application server and database) used
> completely unique keys (e.g. there would be no possibility of a
> "person" object on app server 1 having the same PK as another "person"
> object on app server 2), then I could use the underlying database
> middleware to keep the two databases and applications in sync. Not
> going to work... but still, it's not something that I'm too worried
> about at this point.
>
> Thanks,
>
> -- Steve
>
> On 2 Aug 2004, at 20:23, Art Isbell wrote:
>
>> On Aug 2, 2004, at 12:01 AM, Steve Sharman wrote:
>>
>>> I'd like in the future to be able to implement a mechanism where I
>>> can be absolutely sure that my primary keys are completely unique
>>> across all instances of an application, even if those applications
>>> are running on completely different database and application servers.
>>
>> I must not be understanding your needs. Primary key values are
>> unique within a table in a database. The database guarantees
>> uniqueness. They have nothing to do with application instances or
>> where the app or database are running. All instances of an EO within
>> different editing contexts and in different app instances will have
>> the same primary key value, that which was fetched from the database.
>> This must remain true for EO caching to work correctly and for the
>> correct mapping of an EO to a database row.
>>
>>> I've seen a few references on the list to character primary keys, but
>>> nothing much which is specific on implementation. Is there anywhere
>>> on the web or in the development documentation that shows how this
>>> might be done - presumably it's easy to set up the primary key for an
>>> EO as being of character type, it's the PK generation mechanism that
>>> I'd like to properly understand.
>>
>> http://developer.apple.com/documentation/WebObjects/
>> Enterprise_Objects/Saving/chapter_8_section_5.html#//apple_ref/doc/
>> uid/TP30001011-DontLinkChapterID_14-TPXREF151 discusses the EOF hooks
>> that support custom primary key generation. But how to generate
>> unique primary key values is up to you.
>>
>> Aloha,
>> Art
>> _______________________________________________
>> webobjects-dev mailing list | email@hidden
>> Help/Unsubscribe/Archives:
>> http://www.lists.apple.com/mailman/listinfo/webobjects-dev
>> Do not post admin requests to the list. They will be ignored.
> _______________________________________________
> webobjects-dev mailing list | email@hidden
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/webobjects-dev
> Do not post admin requests to the list. They will be ignored.
>
--
Dov Rosenberg
Conviveon Corporation
370 Centerpointe Circle, suite 1178
Altamonte Springs, FL 32701
http://www.conviveon.com
email@hidden
AOL IM: dovrosenberg
(407) 339-1177 x102
(407) 339-6704 (fax)
(800) 475-9890
(407) 310-8316 (cell)
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.