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?? ;-)
----------------
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.
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]
>
_______________________________________________
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]
