Hi Ricardo,
I've never had the problem you are seeing, but it sounds interesting. I see in
ERXEOControlUtilities.editableInstanceOfObject that willRead() is called on the
EO immediately after localInstance... it would be interesting to know if this
solves the problem as well.
Ramsey
On Jul 7, 2011, at 4:02 PM, Ricardo J. Parada wrote:
> I have the to-many delete rule set to "Cascade". I changed it to "No Action"
> but it was still misbehaving.
>
> BUT, I think I figured it out. Let me tell the whole story. :-)
>
> I inserted the document object into an editing context. This document has no
> children in the to-many relationship yet and it has never been saved to the
> database. The user then clicks a link to open an AjaxModalDialog (AMD).
> When this happens the document object is localInstanced into a child editing
> context. So I then add two children to the to-many and then removed one of
> them. Then when the user clicks DONE in the AMD I then save the changes to
> the parent editing context, the AMD closes and the user may continue editing
> other aspects of the document there. Then the user saves there and changes
> are saved to the database.
>
> Well, it turns out that when I local instanced the document into the child
> editing context I also need to call insertObject on the child editing context
> to insert the document there. I noticed this as the possible culprit because
> when I asked the child editing context for the insertedObjects() the document
> object did not appear in the list. So basically I changed my code that local
> instances the document to something like this:
>
> // Copy document to child editing context
> document = document.localInstanceIn(childEditingContext);
> +++ if (document.isNewObject()) {
> +++ childEditingContext.insertObject(document);
> +++ }
>
> Now EOF behaves as expected!! That seems to be the fix. So I guess that if
> a newly created object that's never been saved to the database is local
> instanced into an editing context then it needs to be inserted into the child
> editing context for EOF to work properly.
>
> I may have learned something new today!! :-)
>
>
>
>
> On Jul 7, 2011, at 5:43 PM, Chuck Hill wrote:
>
>> Hi Ricardo,
>>
>>
>> On 2011-07-07, at 1:52 PM, Ricardo J. Parada wrote:
>>
>>> Hi All,
>>>
>>> I feel odd asking this. It used to be that if I had a to-many relationship
>>> named "foos" and the relationship was setup in the entity modeler to own
>>> the destination objects, then removing objects from the relationship would
>>> cause EOF to delete the objects from the database during saveChanges(). I
>>> have the inverse to-one setup with a delete rule of Nullify.
>>
>> What is the delete rule for the to-many? I think I needs to be No Action.
>> Owns Destination, Propagates Primary Key, and the Delete Rules have
>> interactions which are not easy to remember.
>>
>>
>> Chuck
>>
>>
>>> However, when I saveChanges() the Foo objects removed from the to-many are
>>> being updated to set the inverse to-one with null which blows up because
>>> the database does not accept a null value to avoid orphan Foo objects.
>>>
>>> I'm using Wonder and I see EOGenerator generating the following method in
>>> my _Parent.java :
>>>
>>> public void deleteFoosRelationship(Foo object) {
>>> removeObjectFromBothSidesOfRelationshipWithKey(object, "foos");
>>> }
>>>
>>> which I think is correct. But EOF is not doing the right thing when I
>>> saveChanges(). Has this changed or something?
>>>
>>> If I go to the entity modeler and uncheck "Owns Destination" then
>>> EOGenerator generates the following:
>>>
>>> public void deleteFoosRelationship(Foo object) {
>>> removeObjectFromBothSidesOfRelationshipWithKey(object, "foos");
>>> editingContext().deleteObject(object);
>>> }
>>>
>>> Notice the addition of editingContext().deleteObject(object). So that
>>> fixes my problem but I could swear that EOF used to delete the objects from
>>> the to-many during saveChanges() when the to-many was setup with "Owns
>>> Destination" without me requiring to do
>>> editingContext().deleteObject(object).
>>>
>>> Anybody care to confirm or has some ideas?
>>>
>>> Thanks,
>>> Ricardo
>>>
>>>
>>> _______________________________________________
>>> 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/chill%40global-village.net
>>>
>>> This email sent to [email protected]
>>
>> --
>> 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/rgurley%40smarthealth.com
>
> This email sent to [email protected]
_______________________________________________
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]
