Re: Fat relationships: i.e. user <--->> transactions

Subject: Re: Fat relationships: i.e. user <--->> transactions

From: Joe Moreno <email@hidden>

Date: Wed, 5 Dec 2007 11:51:33 -0800

Delivered-to: email@hidden

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@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:
http://lists.apple.com/mailman/options/webobjects-dev/email@hidden

This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/email@hidden This email sent to email@hidden

References:
	>Java Packages for Dummies (From: Owen McKerrow <email@hidden>)
	>Re: Java Packages for Dummies (From: Chuck Hill <email@hidden>)
	>Re: Java Packages for Dummies (From: Owen McKerrow <email@hidden>)
	>Re: Java Packages for Dummies (From: "Pierce T. Wetter III" <email@hidden>)
	>Re: Java Packages for Dummies (From: Mike Schrag <email@hidden>)
	>Re: Java Packages for Dummies (From: David Avendasora <email@hidden>)
	>Re: Java Packages for Dummies (From: Anjo Krank <email@hidden>)
	>Re: Java Packages for Dummies (From: Mike Schrag <email@hidden>)
	>Re: Java Packages for Dummies (From: Anjo Krank <email@hidden>)
	>Fat relationships: i.e. user <--->> transactions (From: "Pierce T. Wetter III" <email@hidden>)
	>Re: Fat relationships: i.e. user <--->> transactions (From: Patrick Middleton <email@hidden>)