Re: Objects marked for delete fall into the updated objects bucket in processRecentChanges
Re: Objects marked for delete fall into the updated objects bucket in processRecentChanges
- Subject: Re: Objects marked for delete fall into the updated objects bucket in processRecentChanges
- From: Chuck Hill <email@hidden>
- Date: Wed, 6 Aug 2008 09:55:30 -0700
Hi Aaron,
On Aug 6, 2008, at 8:24 AM, email@hidden wrote:
Thank you Chuck and Mike for your thoughts on this rather scary issue.
I will try to free up some cycles to build a "reduction" or "test
case", but probably not today. Assuming I could make a reproducible
and simple reduction, anyone know what Database Apple would most
likely like to see? I'm assuming I might need to use "Derby", which
I've never done before and would be a learning project in itself.
I'd suggest either FrontBase or OpenBase. Use prototypes and they can
use whatever they like for a database.
Mike, thanks for the tip that WOnder's EC already might have Lenny's
fix. I'll look at that and see how it is implemented and if and
where it might be different. Also thank you too Chuck for releasing
the "DeletePrefetcher" code.
The reason Lenny's fix scares me a bit is because it works by
postponing responding to notifications during a save changes until
after the save changes completes. While indeed elegant, it's
possible that some of those notifications could be necessary to
respond to and detremental if they don't get to speak their piece.
Furthermore, applying those notifications after the saveChanges
could cause unwanted behvior too... espeically if it is related to
an eo whose deletion has already been committed to the database and
no longer has an EC associated with it. At a gut level, that's what
bothers me.
I had a look at what it is doing, and I think it is "safe". I suspect
that it blocks notifications for a longer part of the execution of
saveChanges() than in really needed.
While Chuck calls his solution "brutal" it seems like it could be
the better solution. For one thing, the extra logic only kicks in at
the moment you call ec.deleteObject(). So even though it is doing
extra work, it is only doing it at that moment. In that sense, it is
less brutal than Lenny's solution which does extra logic at every
ec.saveChanges(). Additionally, it appears that Chucks code is just
basically prefetching various faults which should be a benign thing
to do. It may cause a few more round trips to the database but it
feels "normal".
I have not gone back to look at the code but I suspect two things are
true:
1. It does little, if any, more fetching that EOF normally does. So
it should only be a waste if saveChanges() is never called.
2. Due to the use of batch fetching it might actually be more
efficient than what EOEditingContext normally does
I still think it is a brutal solution to EOF's bug. :-)
Since I've worked on a number of apps over the years and have just
run into this situation now, I suspect the truth lies somewhere in
the middle between this being an Apple bug and a user bug. I bet
there is something in our EOModels or the way we go about our
business that is somehow "non-standard" and is confusing EOF.
Granted, a deleted object should never get moved into the updated
bucket... and likewise an updated object that is then marked as
deleted should stay in the deleted bucket... that bit does seem like
an Apple bug. But, we might be doing something that could be
avoided, and might be unwise to begin with, that would alleviate the
problems without resorting to work arounds.
I agree that this occurs only in rare situations. I think what is
needed is some cascade delete rules that go through multiple levels
of relationships and an access path where not all of the objects have
previously been fetched. Lenny had a small reproduction case that his
hack fixed. But his hack did not fix my problem so I suspect it is
more complex than that. I really don't think it is a user error.
Chuck
Chuck Hill wrote on 05-08-2008 08:42:12 PM:
>
> File a bug! If you can make a minimal reproduction test case, that
> will help enormously.
>
>
>
> Chuck
_______________________________________________
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
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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