You need ERExtensions, which is core Wonder framework, to get Wonder's NS collection classes. That needs to be in classpath before Apple's foundation framework.
On Jul 8, 2010, at 3:06 PM, Greg Lappen wrote: > I guess I'm confused because I did not actually update the lookup entities > (the ones that had the huge toMany relationship) - I was updating objects > that sit between my main model (LPFile) and the lookup one (LPForm), i.e. I > was deleting, then inserting LPFileForm objects. > > Also, do you mean its likely there as a screwup based on my stacktrace? I > would like to see if I'm using Wonder properly - which framework should I be > using to take advantage of the NSMutableArray.removeObject() fix? > > Thanks! > > On Thu, Jul 8, 2010 at 2:23 PM, Anjo Krank <[email protected]> wrote: > > Yes, EOF will be slow when saving an object with a huge modeled toMany > > relationship since it fetches the entire relationship for validateForSave. > > That's the same stuff they were telling us during WWDC years ago. Back then > "huge" was a guy that bought 20k songs. > > The actual issue is that NSMutableArray.removeObjects() operation was in the > order of n^2 and is now n^log(n) (?) when you use Wonder. And this should > have been fixed in 5.4.3 unless there some sort of screwup. Which seems > likely given your stacktrace. > > Huge now should be well in the 100ks range and more likely be bounded by mem. > > Cheers, Anjo > > > > Am 08.07.2010 um 18:04 schrieb Kieran Kelleher: > > > Yes, EOF will be slow when saving an object with a huge modeled toMany > > relationship since it fetches the entire relationship for validateForSave. > > The solution is to remove the toMany side of the relationship from the > > eomodel and (if needed) add your own business logic for > > fetching/modifying/deleting items in that toMany relationship. > > > > If relationships are not too large, but the db table is really huge and you > > are using a db without proper foreign key support (sadly mysql falls into > > this category with the lack of deferred FK constraints in latest GA > > versions), then you need to make sure you have an INDEX for the foreign key > > of the toMany relationships, otherwise the regular EOF fetch on those > > relationships will be slow due to the sheer size of the foreign db table > > itself. > > > > Hope that helps a little, > > > > Regards, Kieran > > > > On Jul 8, 2010, at 11:14 AM, Greg Lappen wrote: > > > >> does that mean that EO has problems when a one-to-many relationship gets > >> too large? > > > > _______________________________________________ > > 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/anjo%40krank.net > > > > 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/kieran_lists%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]
