Very, very neat.
On Dec 11, 2012, at 1:51 PM, Ramsey Gurley < email@hidden> wrote: If you want to do it all the time, you can supply your own ERXEC factory to do it. Something like the following in your application
public class Factory extends ERXEC.DefaultFactory { @Override public EOEditingContext _createEditingContext(EOObjectStore parent) { EOEditingContext ec = super._createEditingContext(objectStore); ec.setRetainsRegisteredObjects(true); return ec; } }
Then just call
ERXEC.setFactory(new Factory());
somewhere during startup.
Ramsey On Dec 11, 2012, at 4:37 PM, Johnny Miller wrote: Hi Maik and Ramsey,
Understood. This app has a few users who are writing all the time so i'm not worried about memory as much as I'm worried about it:
A. Working B. Users see each other's writes.
So I'm going to play it safe and just set setRetainRegistedObjects(true) in most cases.
Thanks again this really had me worried.
Johnny On Dec 11, 2012, at 1:29 PM, Ramsey Gurley < email@hidden> wrote: I think you have to set it on the parent and you have to do it while the context is fresh. If you fetch EOs into a context and then set it, I believe it will throw an exception. That's my recollection of it anyway :-)
Ramsey On Dec 11, 2012, at 4:25 PM, Maik Musall wrote: Hi Johnny,
I'm not entirely sure, but I think you need to setRetainRegisteredObjects(true) on the parent immediately after the parent's creation if you ever plan to create child editing contexts on it. That's what I do, although it costs memory if you can't always decide that at parent's creation time. In that respect, my previous comment was too unprecise, sorry.
But let's see what Ramsey says.
Maik
Am 12.12.2012 um 00:17 schrieb Johnny Miller < email@hidden>: Hi Maik,
Does this look right to you?
public EOEditingContext ec() {
if(null == _ec) { _ec = ERXEC.newEditingContext(); }
return _ec;
}
public EOEditingContext childEc() { ec().setRetainsRegisteredObjects(true); return ERXEC.newEditingContext(ec(), false); }
public createObject() { EOEditingContext childEc = childEc(); // create the object }
I'm just wondering if it's OK that _ec could be around for a while before I setRetainsRegisteredObjects to true on it.
Thanks a lot! On Dec 11, 2012, at 1:02 PM, Maik Musall < email@hidden> wrote: Do it immediately after creating the child editing context. Am 11.12.2012 um 21:57 schrieb Johnny Miller < email@hidden>: Thank you kind Sir. I thought i was going crazy.
When do you use setRetainsRegisteredObjects? When the EO is initialized?
Thanks a million!
On Dec 11, 2012, at 10:41 AM, Ramsey Gurley < email@hidden> wrote: This is a known issue when using child editing contexts. The only current workaround I'm aware of is:
parentEC.setRetainsRegisteredObjects(true);
Ramsey On Dec 11, 2012, at 1:37 PM, Johnny Miller wrote: Hello everyone,
I'm having problem with a newly deployed app where these errors are popping up intermittently all over the place.
I was wondering if maybe I could get some advice on whether some things I'm doing are possibly causing this...
1. I'm only using ERXEC
2. I'm not explicitly using lock or unlock anywhere. 3. I'm creating new EOs with a child EditingContext - I'm going to go to peer editing context in new build but in some cases I just can't do this i.e. the EO is created using a wizard and I don't want to insert the EO unless the user completes the wizard. 4. I'm using EOEditingContext.setDefaultFetchTimestampLag(0) in the application constructor.
This app has a fair amount of data and a few users who are crunching away on it, constantly adding and updating records. I set item 4 to 0 because I was worried about users viewing data that is out of sync.
Could #4 be tripping the error?
Aloha,
|
Mr. Johnny Miller
Web Development Manager
Kahalawai Media Company
Lahaina, HI 96761
tel: (808) 661-7962 | mobile: (808) 283-0791
website | e-mail
|
|
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
|