Re: Question about 1-to-many relationship
Re: Question about 1-to-many relationship
- Subject: Re: Question about 1-to-many relationship
- From: Chuck Hill <email@hidden>
- Date: Wed, 13 Jul 2011 17:41:49 -0500
Hi Richardo,
On 2011-07-07, at 7:09 PM, Ricardo J. Parada wrote:
> Hi Ramsey,
>
> I did not know about ERXEOControlUtilities.editableInstanceOfObject(). It seems to be doing some interesting stuff. :-) But it's not doing an insertObject() if the eo is a new object. So if I try using ERXEOControlUtilities.editableInstanceOfObject() then the problem comes back and it is 100% reproducible in my app. Then I put my code back and things work like a champ. So I'm sticking with my code for now.
>
> Maybe someone with a better understanding of the EOF internals can comment on this and if I'm right that the insertObject() is needed then maybe we should patch ERXEOControlUtilities.editableInstanceOfObject() to do an insertObject() and I would be glad to use it.
>
> Here's a revised version of my code that local instances the object:
>
> // Copy document to child editing context
> +++ boolean isNewObject = document.isNewObject();
> document = document.localInstanceIn(childEditingContext);
> +++ if (isNewObject) {
> +++ childEditingContext.insertObject(document);
> +++ }
>
>
> ---------------
> The question is: When local instancing a new eo (that's never been saved to the database) into a child editing context, does the local instance of the eo need to be inserted into the child editing context?
> ----------------
> Answer: ??? Mike do you know?? ;-)
> ----------------
Generally the answer is No. Or should be no. I think you have found a bug in EOF with how it handles new objects in child ECs and new objects related in that EC.
> See, when I asked the child editing context for the insertedObjects() and noticed that the eo was missing from there it occurred to me that I was violating an EOF commandment that says that you have to insert the eo before you start using it. It has been inserted into the parent editing context but not in the child editing context. So we all know that when we violate EOF commandments then weird things happen at random. Which is what seemed to be happening here.
> Anyways, I'll leave the question open to see if somebody has the answer to it.
I'd need to do more research to give you a definitive answer. What you are doing sounds like it is working around a bug in EOF. I don't know if your work around could cause other problems or not.
Chuck
> On Jul 7, 2011, at 7:12 PM, Ramsey Gurley wrote:
>
>> 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@hidden)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>> This email sent to email@hidden
>>>>
>>>> --
>>>> 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@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>
--
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden