Fat relationships: i.e. user <--->> transactions
Fat relationships: i.e. user <--->> transactions
- Subject: Fat relationships: i.e. user <--->> transactions
- From: "Pierce T. Wetter III" <email@hidden>
- Date: Wed, 5 Dec 2007 10:17:54 -0700
From a discussion about the danger of using
"addToBothSidesOfRelationship" as default behavior.
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)
There's the _user_ side of the website, and there's the admin side.
That's been true of every website I've worked on.
The _user_ side never needs user->transactions.
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.
Anyways, the qualified relationships in Mike's Velocity templates
are cool, but here's my wet dream for EOF:
1. addToBothSides() should skip the inverse if it isn't faulted.
The fact that it will go off and fetch a large to-many when it doesn't
have to as always seemed like a bug to me. That said, I suspect it
does this because the fault might be getting filled from a snapshot
from an editing context sharing the same database context. So its
either fetch, or invalidate the database snapshot, but only at
saveChanges() time because the editing context could be rolled back. I
guess they feel its easier to just
2. I wish qualified/sorted relationships were built into EOF.
This would mean:
a. Changes to entity modeler to link a fetch spec with a
relationship.
b. Adding an object to the "master" relationship would update
the "dependent" relationship as well.
c. Invalidating the object would invalidate the snapshot of
the dependent relationship.
That would mean I could define user->recentTransactions to mean
transactions over the last 30 days, and then everything would "just
work". If I did transaction.setUserRelationship(user) and I'd filled
recentTransactions, the new transaction would show up in user-
>recentTransactions.
3. Inheritance/additions for models. So you can have userModel,
that has a subset of the relationships. Then "adminModel" adds all the
inverse ones.
4. Or perhaps you can just specify the array fault class for a
relationship in EOModeler, and you can specify one that doesn't do the
reverse fetch for add/removes until it has too, and perhaps can even
answer count() without building 10,000 objects. So then you could go
in and specify a "sparse" class for those fat relationships.
Pierce
_______________________________________________
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