• 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
Re: Java Packages for Dummies
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Java Packages for Dummies


  • Subject: Re: Java Packages for Dummies
  • From: Mike Schrag <email@hidden>
  • Date: Wed, 5 Dec 2007 08:44:53 -0500

Also it's an urban legend that simply faulting the objects is slow. This is only true when you either have batch operations where you are not really interested in the relationship but it will get fetched because validation needs it. Or you have *huge* relationships (say >1k objects).

For those that remember from Max Muellers talk how EOF was expensive when inserting into huge relationship - a customer with 20k songs had to wait a long time: this was a only because of a stupid error in NSArray which had O(n^2) and has been fixed in Wonder for a year now.
I agree that you certainly should write the easy way first and only fix it if it's a problem ... But the >1k objects can definitely happen, and for me at least, it tends to be rare that you ever even WANT that inverse relationship. For instance, the case that comes to mind is in our task tracking system, we have EO's that represent the task statuses (this was pre ERXConstant incidentally, though the original requirements were that the list was extendable anyway). 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.

The warning flags go up for "lookup table objects" (like bug type, etc -- anything that you think "enumerated type" when you see -- though you should look at ERXConstant for most of these now) and "write mostly" data (like audit trails, etc -- constantly growing to-many relationships that you rarely actually read the data back out).

But I do recall you fixing that NSArray bug, now, and I actually haven't timed this out ... Might be interesting to see a graph of fault speed as that array size grows on a "normal" sized EO.

ms

_______________________________________________
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: Java Packages for Dummies
      • From: Anjo Krank <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>)

  • Prev by Date: Re: Java Packages for Dummies
  • Next by Date: Re: Java Packages for Dummies
  • Previous by thread: Re: Java Packages for Dummies
  • Next by thread: Re: Java Packages for Dummies
  • Index(es):
    • Date
    • Thread