Re: ERXRestFetchSpecification defaultSortOrderings ordered by id (PK)
Re: ERXRestFetchSpecification defaultSortOrderings ordered by id (PK)
- Subject: Re: ERXRestFetchSpecification defaultSortOrderings ordered by id (PK)
- From: Kieran Kelleher <email@hidden>
- Date: Thu, 15 Mar 2012 13:54:22 -0400
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@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden