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
[EMAIL PROTECTED] failed to find a
snapshot for EO with Global ID:_EOIntegralKeyGlobalID[KitQuantity
(java.lang.Integer)1234] that has been deleted from
[EMAIL PROTECTED] 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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
