Re: mandatory relatoinship preventing deletion?
Re: mandatory relatoinship preventing deletion?
- Subject: Re: mandatory relatoinship preventing deletion?
- From: Chuck Hill <email@hidden>
- Date: Tue, 21 Oct 2003 12:43:01 -0700
- Organization: Global Village Consulting, Inc.
email@hidden wrote:
Hmm, this could be the cause of any mysterious error I'm getting. It's a
hard one to explain, but basically involves an EO, in propagateDelete...
method, tries to remove some destination of one of it's relationships (to
honor the delete propagation), and gets a weird "wrong editing context"
exception. Can't figure out how an EO's own relatoinship destinations
can be in a wrong EC (I do check in all relationship manipulation methods
to make sure you can't give an EO an improperly-ECd destination to a
relationship, so that's not the problem).
Wow, I can't think of what else that might be. Unless one of the bulk
setXxxx(NSMutableArray aValue) methods is setting in an EO in the
wrong EC and you are not checking that.
If a save fails due to an error during propagateDelete... you can
pretty much consider the EC to be permanently gibbled. Yes, its a
bug. Yes, I've reported this. Yes, Apple is aware. Maybe this will
be fixed in 5.2.2 but I'm not holding my breath.
You can somewhat avoid this by using an EC subclass that clears the
undo stack after a successful save.
If these two exceptions are related, it would be interesting, as they are
both my biggest annoyances right now. Hard to reproduce, can't figure out
what the heck is going on.
It sounds to me like they are related.
But I still can't figure out what's going on. I'm not getting any other
mysterious logged exceptions immediately prior to the one's we're talking
about. If the one's we're talking about are just a sort of side effect of
some EOF stack corruption, I can't figure out what's causing the EOF
stack corruption.
I've never seen the crossed-ec problem caused by anything other than
programmer error. That is a weird one and probably the root cause.
As far as I know, I lock all ECs. I've never succeeded in turning on
warnings for unlocked ECs, so I could be wrong. But I'm pretty sure I'm
succesfully locking all ECs.
Trouble turning it on on Solaris or some other platform?
Hmm. Any other ideas or hints or possible solutions would be welcome.
When you did see things like this before, how did you solve them?
I've seen the mandatory relationship being validated as non-null
before but only when preceeded by another save (delete) faliure. I
just added code to validate the deletion before trying the save and
also cleared the undo stack after saving. Nasty, but so far it seems
to be working.
Chuck
--Jonathan
On Tue, 21 Oct 2003 11:16:22 -0700 Chuck Hill wrote:
I've seen things like this before from failed saves and from not
locking editing contexts. Particularly failures from deletes that
failed validation, but errors at the adaptor level *may* also cause
this. I think the root cause was the ec rolling back the undo stack
too far.
What seems to be happening is the nullify delete rule is nulling the
department and then the object is being re-validated for save.
Or, perhaps, you have a nullify delete rule when you should have no
action.
That is all I can think of now.
Chuck
email@hidden wrote:
[demime could not interpret encoding binary - treating as plain text]
Having a relationship set to 'mandatory' shouldn't prevent
deletion, should it?
I have two entities, which I'll call Employee and Department. Employee
has a mandatory to-one to Department. When I try to delete an
Employee.... I get a validation exception saying "the department
property
of Employee must have a Departmetn assigned." Huh? But I'm trying to
delete it. And it did have a Department assigned before I deleted it. I
don't get it.
--Jonathan
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
Progress is the mother of all problems.
- G. K. Chesterton
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
Progress is the mother of all problems.
- G. K. Chesterton
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.