This can't work. 

  s isn't saved in the child, so you can't fault it into the parent.

You *should* be able to fault m into the child, though.

Thanks for wasting 10 mins of my time.

Cheers, Anjo



Am 16.02.2010 um 23:31 schrieb David LeBer:

> 
> On 2010-02-16, at 5:19 PM, Chuck Hill wrote:
> 
>> On Feb 16, 2010, at 2:17 PM, David LeBer wrote:
>>> On 2010-02-16, at 4:41 PM, Chuck Hill wrote:
>>> On Feb 16, 2010, at 1:32 PM, David LeBer wrote:
>>>> 
>>>>> This is something I've run into multiple times, hacked something to work, 
>>>>> and then thought there must be a better way.
>>>>> 
>>>>> The scenario:
>>>>> ------------------
>>>>> 
>>>>> I have Studio <studio*----------movies>> Movie
>>>>> 
>>>>> If I create a new Studio, I will use a generic Studio edit form to set 
>>>>> it's values, the form has a button that allows the user to add a new 
>>>>> related Movie.
>>>>> 
>>>>> Here's the conundrum:
>>>>> ------------------------------
>>>>> 
>>>>> - If I use the same EC for the Movie, and the user cancels in the Movie's 
>>>>> Edit form, the EC will get reverted (bad).
>>>>> - If I use a nested EC for the Movie, I cannot build a relationship 
>>>>> between it and the Studio (because they are in different ecs), I cannot 
>>>>> call local instance on the Studio because it hasn't been committed yet,
>>>> 
>>>> Does that not work?  I thought it did as the parent is the child's OSC so 
>>>> it can get the object copied into it.
>>> 
>>> I thought for sure I tested that it didn't. But of course, after double 
>>> checking, it does. Well, despite making me feel like an idiot, this is a 
>>> good thing... thanks for that Chuck ;-)
>> 
>> If it makes you feel any better I was worried that I might look like an 
>> idiot when you tested it.  :-)  You were probably thinking of doing this 
>> between two unrelated ECs when it definitely does NOT work.
> 
> It definitely doesn't work trying to pull an EO in a child ec into it's 
> parent's. i.e:
> 
>       EOEditingContext rootEc = ERXEC.newEditingContext();
>       EOEditingContext childEc = ERXEC.newEditingContext(rootEc);
>       Movie m = Movie.createMovie(rootEc, "Test", null);
>       Studio s = Studio.createStudio(childEc, new BigDecimal(100.00), "Test");
>       Studio localS = s.localInstanceIn(m.editingContext());
> 
> BOOM: "You attempted to localInstance 
> <org.wocommunity.movies.model.server.Studio pk:"null">, which has not yet 
> committed."
> 
> I thought I'd gotten a similar message when I tried the other way around, but 
> I probably got distracted and... OOH! SHINY!... 
> 
> 
>> 
>> 
>> Chuck
>> 
>> 
>> 
>>> 
>>> So this works:
>>> 
>>> Movie m = Movie.createMovie(ERXEC.newEditingContext(), "Test", null);
>>> Studio s = Studio.createStudio(ERXEC.newEditingContext(m.editingContext()), 
>>> new BigDecimal(100.00), "Test");
>>> 
>>> Movie localM = m.localInstanceIn(s.editingContext());
>>> //EO from a parent EC into it's nested child via localInstance works.
>>> 
>>> s.addObjectToBothSidesOfRelationshipWithKey(localM, Studio.MOVIES_KEY);
>>> s.editingContext().saveChanges();
>>> 
>>> m.editingContext().saveChanges();
>>> 
>>> 
>>>> 
>>>> 
>>>> Chuck
>>>> 
>>>> 
>>>>> and I cannot call local instance on the Movie until after it's ec has 
>>>>> been saved, which will unfortunately throw a validation error (because 
>>>>> it's Studio relationship is required in the model).
>>>>> 
>>>>> Things I've done in the past:
>>>>> -------------------------------------
>>>>> 
>>>>> - Disable adding Movies to a Studio until the Studio has been committed 
>>>>> (then local instance will work).
>>>>> - Modify the model so that the  to-one relationship from Movie -> Studio 
>>>>> is not mandatory, and hide the to-one edit widget in the Movie form for 
>>>>> newly minted Movies, and then set the relationship between the two AFTER 
>>>>> the Movie has been successfully saved and we are heading back to the 
>>>>> Studio form.
>>>>> 
>>>>> When rolling my own edit forms, this not so much of an issue, but in D2W 
>>>>> where everything is generic it bites, I hate having to write custom rules 
>>>>> and modify the model to work around this.
>>>>> 
>>>>> Anyone have an magical solution that I am missing?
> 
> ;david
> 
> --
> David LeBer
> Codeferous Software
> 'co-def-er-ous' adj. Literally 'code-bearing'
> site:         http://codeferous.com
> blog:         http://davidleber.net
> profile:      http://www.linkedin.com/in/davidleber
> twitter:      http://twitter.com/rebeld
> --
> Toronto Area Cocoa / WebObjects developers group:
> http://tacow.org
> 
> 
> 
> 
> _______________________________________________
> 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/anjo%40krank.net
> 
> 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]

Reply via email to