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
_______________________________________________
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]
