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.


> (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


> 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/chill%40global-village.net
> 
> This email sent to [email protected]

-- 
Chuck Hill             Senior Consultant / VP Development

Practical WebObjects - for developers who want to increase their overall 
knowledge of WebObjects or who are trying to solve specific problems.    
http://www.global-village.net/gvc/practical_webobjects








Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
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]

Reply via email to