My 2¢:
The following code snippet works for me in most cases, but, it
doesn't work if the app tries to access the to-many relationship
prior to saving the changes to the database. Such access would fire
the fault which would not contain the added object because it hadn't
been saved to the DB, yet it should be in the to-many relationship in
the app's object graph because it had been added.
public void holdFaultWhenAdding(EOEnterpriseObject eo, NSArray
toManyArray) {
if(!EOFaultHandler.isFault(toManyArray)) {
NSMutableArray array = (NSMutableArray) toManyArray;
this.willChange();
array.addObject(eo);
}
}
When using the above method to hold faults, you’ll need to replace
addToRelationship in your EO’s
custom class.
public void addToProducts(Product product) {
this.holdFaultWhenAdding(product, this.products());
}
Does anyone have any experience with modeling the relationship both
ways and simply turning off the to-many side as a class property for
the _user_ side of a Web site but leaving the relationship as a class
property for the_admin_ side?
I'm just thinking out loud, but it seems that both the _user_ and
_admin_ apps could use the same EO Model but the _user_ app could
load the model and then dynamically turn off the to-many relationship
as a class property during run time.
- Joe
On Dec 5, 2007, at 09:53:22, Patrick Middleton wrote:
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 PROTECTED]
England (MIME welcome)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/joemoreno%
40mac.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:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
