• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Fat relationships: i.e. user <--->> transactions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
  • Follow-Ups:
    • Re: Fat relationships: i.e. user <--->> transactions
      • From: Mike Schrag <email@hidden>
    • Re: Fat relationships: i.e. user <--->> transactions
      • From: Patrick Middleton <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>)

  • Prev by Date: Re: class loader launch problem with Wonder
  • Next by Date: Re: ExistsInRelationshipQualifier
  • Previous by thread: Re: Java Packages for Dummies
  • Next by thread: Re: Fat relationships: i.e. user <--->> transactions
  • Index(es):
    • Date
    • Thread