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:
|