On 16/03/2012, at 6:54 AM, Kieran Kelleher wrote:
> 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);
>
So are you saying I can create a EOSortOrdering based on my PK ('id') without
exposing it as a class property by doing this - Is that right?
If so, that's probably the answer I was after - Providing of corse I was to
ignore the ethical debate on wether or not to use the PK at all in the first
place
>
>
> 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]
