On Aug 4, 2008, at 8:21 AM, [EMAIL PROTECTED] 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 protected]/msg04553.htmlI'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
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 protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
