OK, at the risk of chastisement, I disagree with David A and probably all of my
other friends! :-)
(1) Don't make 'id' a class property - IIRC, it may cause problems with PK
generation.
(2) You *can* use a non-attribute PK named "id" (or whatever) as a sort *key*
in a EOFetchSpecification .... you just can't use it for "in-memory" sort.
EOSortOrdering s = new EOSortOrdering("id",
EOSortOrdering.CompareAscending);
BTW, you can even use "id" for EOQualifiers, again only in a
EOFetchSpecification that will generate SQL and fetch, but not in an
EOQualifier that will be used for in-memory qualification.
So in reality, the difficulty is that primary and foreign keys are treated in a
special way .... and philosophically many will say "it's an artifcact of the
database - pretend it does not exist. Make another field with a unique ID,
etc." - IMHO, if exists, it is real and probably for the lifecycle of your
application, the PKs with never change and while some disagree, I am all for
using "id" to sort or qualify a fetch if needed rather than invent some whole
feature to avoid using it.
If I was going to compromise, then I would simply make a field called UniqueID,
and I would override willInsert and set that field to the same value as
ERXGenericRecord.rawPrimaryKeyInTransaction(). yes, I *would* simply use EOF's
PK as the value of my UniqueID field. Your PK will never change for the life if
your database through normal WebObjects usage.
My 2 cents,
-Kieran
On Mar 15, 2012, at 12:15 PM, David Avendasora wrote:
> On Mar 15, 2012, at 4:00 PM, Rich wrote:
>
>> Hi Paul,
>>
>> Thanks, I'll have a look into that - I really new to WO, and still finding
>> my feet, so was unaware of ERXGenericRecord.
>>
>>
>> On 15/03/2012, at 6:22 PM, Paul Hoadley wrote:
>>
>>> On 15/03/2012, at 3:25 PM, Rich wrote:
>>>
>>>> Obviously NOT ideal, but unless anyone has a suggestion on a 'cleaner /
>>>> propper' way to expose it, then I think it will suffice for the
>>>> 'Prototype' - I'll change it in the 'production' version if it get's that
>>>> far (honest)
>>>
>>> Assuming you're extending ERXGenericRecord, won't primaryKey() or
>>> rawPrimaryKey() do what you want?
>>>
>
> I would _highly_ recommend defining a secondary, unique, incrementing key,
> maybe call it "SyncID" and have it populated by a trigger or sequence
> something similar on commit and NOT make use of the database's PK. It's the
> database's and all you can count on is that it is UNIQUE, not that it is
> really in order. It is entirely possible for EOF to request several hundred
> IDs at once and assign them to EOs in one editing context while a second
> editing context comes along and requests some and saves _before_ the first ec
> does. Sure this isn't the _normal_ way it is done, but who knows what the
> next developer is going to do with your code and he/she probably will have an
> entirely different set of assumptions.
>
> PKs and FKs are artifacts of the implementation of a relational database.
> Don't assign them business meaning. Create your own fields and attributes to
> represent business meaning.
>
> Dave
>
> —————————————————————————————
> WebObjects - so easy that even Dave Avendasora can do it!™
> —————————————————————————————
> David Avendasora
> Senior Software Abuser
> Kaiten, Inc.
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/kelleherk%40gmail.com
>
> This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
