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: Tue, 5 Aug 2008 17:42:12 -0700
On Aug 4, 2008, at 8:21 AM, email@hidden wrote:
Hello WOrriors,
What, me worry?
We're using WO 5.3.x (not 5.4.x)
I've run into a pickle where if I do an ec.deleteObject() and then
call ec.saveChanges() I find that this fails during a
"validateFor*Save*". Curious, indeed, because it should only call
"validateFor*Delete*".
If you don't have a validateForDelete() method, EOF will call
validateForSave().
When asking the EC to delete the Object, it breaks various mandatory
relationships. This, in itself, is ok because the object is about to
go "bye-bye" and is akin to setting a variable to null so you don't
accidentally try to reference it anymore.
I am not quite following what is happening. If the relationships are
mandatory, you can't break them. That should cause delete rule
failures during save changes.
Problem is, the object is mysteriously being dropped into the
"updatedObjects" bucket during "processRecentChanges()"... this is
what kicks off the validateForSave which of course fails because
mandatory relationships are purposely broken.
I suspect that is not quite it. Are you sure that this is happening
in processRecentChanges()? There is a bug in 5.3.3 and prior (not
sure if still in 5.4.2), in EOEditingContext that causes problems when
a fetch is performed while processing a saveChanges messge. When a
fetch occurs a notification is sent to the editing context which
causes it to discard some cached information regarding inserted,
updated, and deleted objects. When this happens during certain phases
of the save it causes the editing context to lose track of what it is
doing. This is a particular problem when processing delete rules.
This results in things such as updates being sent instead of deletes
and validation being performed after deletion resulting in null
required attributes where key fields have neen set to null.
That sounds more like what you are seeing.
Even more of interest is that this strange transfer from "deleted ->
updated" status only happens in certain repeatable circumstances. It
happens when you:
1) On _page A_ in _EC 1_ *edit a value in the desired EO and save*
2) then go to a different _page B_ with _EC 2_ but pass the EO as a
local object of the new EC
That would result in the EC firing a fault. That probably also
triggers this bug.
3) Attempt to delete and save the local EO in _EC 2_ on _page B_.
The above will happen every time. However, if I repeat those above
steps but "do not edit the EO" in step 1, then everything goes
according to plan and the object actually deletes.
This is all on my local machine in dev mode with DirectConnect.
Nothing funny with multiple concurrent access. Strangely, if I step
into ec.saveChanges() and then ec.processRecentChanges() and step a
bit there then hit "continue" in the debugger... the marked for
delete object *stays* in the delete bucket and deletes as desired.
So odd! It's as if there is a concurrent process going on in
processRecentChanges that if tripped at the right time, maybe a
deferred fault (or something) gets fired and causes an object to
move from the deleted -> updated bucket.
I've searched a bit on the listserv archives and have seen some
notable people have had similar issues in the past. For example this
posting between Lenny, Chuck, and Christian:
http://www.mail-archive.com/email@hidden/msg04553.html
I've tried the code fix to EOEditingContext offered here and found
that it stops the Validation Error but doesn't actually delete the
desired EO either.
If anyone has any insight on this issue I'm all ears and appreciate
your thoughts and concern. Anything like:
1) Is this a confirmed bug by Apple that might be fixed in WO 5.4 or
at least has an open Radar ticket?
I have an open ticket on a possibly related item. Since, er, 2003.
2) Is there possibly something similar that has bit you that you
think I also might be doing wrong and overlooking?
It is a bug.
3) Have other peoople used Lenny's fix and had any other thoughts or
tweaks?
I tried it. My notes say,
It was originally thought that this problem would also be solved by
using DeleteFiresFaultWorkAroundEditingContext. However, when working
on release 4.6 of GVC.SiteMaker, it was discovered that this does not
address all of the issues. Delete operations get changed into
updates, or deletes fail EOF update validation if this class is not
used. This problem may be specific to some oddity in the EOModels
used by GVC.SiteMaker.
I will attach what I use. It is brutal, but works. You can use it in
an EC sub-class like this:
protected DeletePrefetcher deletePrefetcher = new
DeletePrefetcher();
public void deleteObject(EOEnterpriseObject object)
{
deletePrefetcher.reset();
deletePrefetcher.prefetchDeletionPathsFrom(object);
super.deleteObject(object);
}
File a bug! If you can make a minimal reproduction test case, that
will help enormously.
Chuck
Attachment:
DeletePrefetcher.java
Description: Binary data
--
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