Re: ERXRestFetchSpecification defaultSortOrderings ordered by id (PK)
Re: ERXRestFetchSpecification defaultSortOrderings ordered by id (PK)
- Subject: Re: ERXRestFetchSpecification defaultSortOrderings ordered by id (PK)
- From: Ramsey Gurley <email@hidden>
- Date: Thu, 15 Mar 2012 11:41:04 -0700
On Mar 15, 2012, at 11:03 AM, Chuck Hill wrote:
>
> On 2012-03-15, at 10:54 AM, Kieran Kelleher wrote:
>
>> OK, at the risk of chastisement, I disagree with David A
>
> That is just sensible.
>
>
>> and probably all of my other friends! :-)
>>
>> (1) Don't make 'id' a class property - IIRC, it may cause problems with PK generation.
>
> It is "OK"* to make the PK a class property. It is making the FK a class property that causes problems.
>
> * Technically OK, philosophically is a different question.
Exposed PKs tends to lead to exposed FKs and worse. Just sayin... Even if I had a natural key, I'd create a surrogate key anyway and put a unique index on the natural key.
>
>
>> (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.
>
> I agree with Kieran here. That will probably give David A conniptions.
>
>
> Chuck
Dave A's point still stands though. The ID is unique, but not necessarily in any particular order. I'd go with a dateCreated column populated in willInsert() or init(). Using the pk to determine the date created is just sloppy and will come back to haunt Rich one day. If Rich wants something that's easy to sort with JSON, then I would suggest formatting the date as a value that sorts easily and send that down to the client. YYYY-MM-DD, date.getTime() or something.
Ramsey
_______________________________________________
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