Please let us know what you find out. Chuck
On 2011-07-13, at 4:39 PM, Ricardo J. Parada wrote:
>
> Well I'm not so sure yet... :-) I'm backed out my change today. After more
> testing another case was found were EOF was misbehaving and I was able to fix
> it today by backing this out. The weird thing is that the other bug that
> this was supposed to fix is not reproducible. But other things in the UI of
> the app changed. So who knows. I'm seriously questioning whether this code
> was really needed. I really don't have any scientific proof. :-)
>
> So I'm just gonna wait and see how it goes on the testing. :-)
>
> Thanks
>
>
> On Jul 13, 2011, at 6:41 PM, Chuck Hill wrote:
>
>> 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 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]
>>>>
>>>
>>
>> --
>> 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
>>
>>
>>
>>
>>
>>
>>
>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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]
