Re: deleteSelection sets relationship null rather than deleting
Re: deleteSelection sets relationship null rather than deleting
- Subject: Re: deleteSelection sets relationship null rather than deleting
- From: Chuck Hill <email@hidden>
- Date: Fri, 7 Oct 2005 11:33:40 -0700
Ian,
I've finally found the time to go back and look at this. The problem
is not, as I recalled, an EOModel problem. There is a bug in
EOEditingContext that causes problems when a fetch is performed (i.e.
EOF fires a fault) while processing a saveChanges message. When the
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 process 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
been set to null.
My work around for this is to pre-process the delete rules for all
objects being deleted to ensure that all affected or referenced
objects have been fetched before the save process is allowed to
start. This does not fix the problem but it avoids the symptoms. I
can point you to the code if this sounds like it may be your problem.
Chuck
On Oct 5, 2005, at 5:59 PM, Ian Joyner wrote:
Thanks Chuck and Art. If it is a bug in WO, I don't think it is a
difference in the two keys, because all my keys are taken from two
prototypes, 'primary_key' and 'foreign_key'. These are exactly the
same, so really only serve a documentation purpose (since setting
an attribute to 'primary_key' clears the PK property in EOModeler
anyway). Although, I could even do away with this distinction since
all my primary keys are really imaginatively named 'primary_key',
since they serve no more semantic purpose. But then again this name
comes directly from the 'primary_key' prototype, so maybe I'll keep
the two, since foreign keys do have to be renamed.
I think there could be a bug in WO still because the Desktop Apps
book tells you to do things, connecting remove buttons up to the
display group's deleteSelection method. I got it to work with Art's
suggestion, but did not need the removeFromBothSides... bit. The
following code works:
// Telephones ---------------------------------------
public EODisplayGroup telephones_display_group;
public void remove_telephones () {
remove_selected_objects (telephones_display_group,
editingContext ());
}
public void remove_selected_objects (EODisplayGroup
from_display_group, EOEditingContext in_editing_context) {
// I don't think this is theoretically needed, but in some
cases, deleteSelection only
// causes the keys to be set to NULL, rather than deleting
the DB record.
// require
// from_display_group /= null
// in_editing_context /= null
java.util.Enumeration e =
from_display_group.selectedObjects ().objectEnumerator ();
while (e.hasMoreElements ()) {
in_editing_context.deleteObject ((EOEnterpriseObject)
e.nextElement ());
}
from_display_group.deleteSelection ();
}
but shouldn't this be what EODisplayGroup.deleteSelection is doing
anyway? Perhaps the editing context for the object is not set up
correctly because I can't see where EODisplayGroup would get it
from otherwise?
Thanks
Ian
On 06/10/2005, at 3:03 AM, Chuck Hill wrote:
I've seen this before. It has been a while now. My recollection
is that this was caused by a bug in EOF (no, really!) which was
triggered by differences in the datatype or value type (both as
set in the EOModel) between the keys in the two entities.
Chuck
On Oct 4, 2005, at 11:16 PM, Ian Joyner wrote:
On 05/10/2005, at 10:42 AM, LD wrote:
Hi Ian,
On 04/10/2005, at 4:11 PM, Ian Joyner wrote:
I have a reflexive many-to-many contacts relationship modelled,
as you would expect through a join table. The entity is defined
as follows:
attributes:
primary_key not null
relationship: string
contact_key not null
owner_key not null
relationships:
contact: contact_key -> Person.primary_key (optional) on
delete, nullify
owner: owner_key -> Person.primary_key (optional) on delete,
nullify
If your relationships are optional then the corresponding keys
(contact_key, owner_key) should also be optional rather than
'not null'. That'd be a start in getting it right...
Yes setting the keys to may be null removes the error, but only
sets the key to null – it does not delete the record. Anyway,
since this is a join record, it only makes sense to make the
relationships mandatory, since the other two parties must exist
and be referred to for this record to make any sense.
However, I have just found that I have the same problem with
telephones, which is simpler and does not involve a join record
since it is a one-to-many relationship and the phones don't
bother with the owner relationship on the owner_key. Thus I have:
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Coming in 2006 - an introduction to web applications using WebObjects
and Xcode http://www.global-village.net/wointro
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