Re: Fat relationships: i.e. user <--->> transactions
Re: Fat relationships: i.e. user <--->> transactions
- Subject: Re: Fat relationships: i.e. user <--->> transactions
- From: Patrick Middleton <email@hidden>
- Date: Wed, 5 Dec 2007 17:53:22 +0000
On 5 Dec 2007, at 17:17, Pierce T. Wetter III wrote:
...
"addToBothSidesOfRelationship"
...
It turns out to be almost never the case that you want to fetch
all "Open Tasks". It tends to be the case for us that you almost
always want to have additional qualifiers on those searches,
which ends up that you fault a HUGE (many thousands) of EO's in
just to turn back around and filter them down in memory.
Instead, I can remove that relationship completely and provide
just the variant of the to-many that takes a qualifier.
Of course not and I agree 100%. But the example was user <-
>>transactions which *I* would not fetch manually unless I had
problems with multiple instances.
And the case above would normally be in an SEC which would have no
outgoing relations anyway.
Well, it was my example, so I'll chime in (and change the subject)
...
The _admin_ side often does. So I'm glad to hear there's a fix
for the NSArray O(N^2) issue, that was in old Obj-C EOF as well.
So removing the inverse relationship from a fat to-many isn't
always an option if you need one in one place, and another in a
different place.
A pure EOF solution would be to dynamically define the to many
side of
user ->>transactions relationship at runtime, based on the
particular application's needs.
That was one of the nice things about Obj-C categories...I could
load certain code in only certain places.
...
Suddenly I am reminded of some ObjC code I posted to this list on Apr
19 ("Re: AddObjectToBothSidesOfRelationshipWithkey") -- how to
manipulate relationships in a clean(ish) fully EOF 4.5.1 way that
avoids unnecessary firing of array faults.
--
Patrick Middleton
OneStep Solutions plc
351 London Road Phone: +44 (0)1702 426400
Hadleigh Fax: +44 (0)1702 556855
Essex. SS7 2BT Email: email@hidden
England (MIME welcome)
_______________________________________________
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