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: Wed, 5 Oct 2005 10:03:02 -0700
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:
PERSON
attributes
primary_key not null
relationships
telephones: primary_key ->> Telephone.owner_key (optional), on
delete cascade, owns destination
TELEPHONE
attributes
primary_key not null
owner_key not null
relationships
none
So the problem seems to be independent of how the relationships are
set up and the owner of the telephone is indeed mandatory, so the
key is not null.
Now I get:
[2005-10-05 15:45:25 EST] <WorkerThread6>
com.webobjects.eoaccess.EOGeneralAdaptorException:
EvaluateExpression failed:
<com.webobjects.jdbcadaptor.OpenBasePlugIn$OpenBaseExpression:
"UPDATE TELEPHONE SET OWNER_KEY = NULL WHERE (PRIMARY_KEY = ? AND
LOCATION_KEY is NULL AND NUMBER = ? AND KIND_KEY = ? AND TYPE_KEY
= ? AND AREA_CODE = ? AND COUNTRY_CODE = ? AND OWNER_KEY = ? AND
OWNER_TYPE = ?)" withBindings: 1:528(primary_key),
2:"447567"(number), 3:16(kind_key), 4:18(type_key),
5:"345"(area_code), 6:"61"(country_code), 7:308(owner_key),
8:"P"(owner_type)>:
Next exception:SQL State:42000 -- error code: 0 -- msg: ERROR -
Value can not be NULL for column 'OWNER_KEY'
SQL: UPDATE TELEPHONE SET OWNER_KEY = NULL WHERE (PRIMARY_KEY = 528
AND LOCATION_KEY is NULL AND NUMBER = '447567' AND KIND_KEY = 16
AND TYPE_KEY = 18 AND AREA_CODE = '345' AND COUNTRY_CODE = '61' AND
OWNER_KEY = 308 AND OWNER_TYPE = 'P')
instead of
DELETE TELEPHONE WHERE ........
Any ideas appreciated
Ian
_______________________________________________
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