Hi Ken,
Thanks for writing. If not, how do you keep things from getting stuck in the database half finished all over the place? Tons of local variables?
I'm not sure why this would happen. If you destroy the child editing context without saving to the parent, you should not have anything half finished anywhere.
I wasn't very clear here. What I meant to say was that I'm attempting to use nested editing context as a means of preventing people from setting a few attributes of an EO, not committing, going to another totally unrelated page, and committing the previous changes from before when they save. Nested editing contexts seem to be one means of accomplishing this. I'm having all kinds of difficulties with them, so I'm looking for other alternatives. One other alternative would be to define a dictionary or a bunch of local variables per page to bind to, and only copying those into an EO when you are ready to commit. However, this requires a lot of extra boring work, since you would have to bind to each local variable (instead of just binding to the EO's attributes) and then copy those over to the relevant EO's when you were ready to commit. Since the thing I've been doing for years (not inserting the object) has been getting so much bad press lately, and the suggested alternative (nested ECs) is causing me to lose tons of sleep, and the other alternative I can think of seems like a lot of boring work, I'm asking if there are other alternatives or at least if others are having the same experiences I am having with nested ECs. And if so, is no one else seeing these kinds of ridiculous corrupted snapshot problems? Honestly, I don't. Can you give us some examples of your usage of nested contexts and why you end up with half finished data?
Ken
As explained above, I don't end up with half finished data, but I do end up with corrupted snapshots in EODatabase which cause exceptions when I try to do fairly trivial things. Here is the setup... I have a nested editing context reference in session (nested in the session's default editing context):
-----------------Session.java----------------
protected EOEditingContext _nestedEC; protected boolean _lockedNested;
public Session() { super(); _nestedEC = ERXEC.newEditingContext( defaultEditingContext() ); _lockedNested = false; }
public EOEditingContext nestedEC() { return _nestedEC; }
public EOEditingContext getAndRevertNestedEC() { _nestedEC.revert(); return _nestedEC; }
public void awake() { super.awake(); _nestedEC.lock(); _lockedNested = true; }
public void sleep() { try { if ( _lockedNested ) { try { _nestedEC.unlock(); } catch ( Exception e ) { NSLog.out.appendln( "unlock without lock: " + e ); } _lockedNested = false; } } catch ( Exception e ) { NSLog.out.appendln( ErrorStackTrace.toString( e ) ); } super.sleep(); }
-----------------Session.java----------------
Within my "Edit" page, I have an instance variable that I call _nestedEC which gets initialized by calling session.getAndRevertNestedEC();
I can create EOs, insert them into _nestedEC, save _nestedEC, save session.defaultEditingContext(), and everything is great. If I then immediately delete the newly saved and created EOs:
_nestedEC.deleteObject(objectToDelete); _nestedEC.saveChanges(); ec.saveChanges();
I will eventually randomly get something that looks like this:
java.lang.IllegalStateException: recordDeleteForObject: com.webobjects.eoaccess.EODatabaseContext com.webobjects.eoaccess.EODatabaseContext@a0fcdc failed to find a snapshot for EO with Global ID:_EOIntegralKeyGlobalID[KitQuantity (java.lang.Integer)1234] that has been deleted from er.extensions.ERXECer.extensions.ERXEC@419cf7. Cannot delete an object that has not been fetched from the database
Furthermore, if I examine the state of the snapshots, I can see that they get in all kinds of terrible shape as I add/delete things in the nested EC and save changes. I should clarify one point. _nestedEC's snapshots of the objects seem fine, but the default editing context's snapshots just go to hell in no time if I don't use EODatabase.disableSnapshotRefCounting() in my application's constructor. Do you do this in your applications?
Thanks, Mark |