"rollback" of instance attributes?

AttributeManager can "roll back" the values of all attributes to the last CommittedState taken. Currently, a CommittedState is taken when an object is first loaded, and after each flush. if we wanted session.rollback() to also roll back all the instance attributes without needing to "expire" everyone (thus resulting in much SQL issued):

AttributeManager.commit() could be expanded to take a string argument "commitpoint" or similar, which saves multiple CommittedState instances
Session would save one CommittedState per instance at object load time, and a second one after a flush(). Each flush() replaces that second CommittedState assuming we're still in a transaction.
when Session "commits" its transaction, AttributeManager.commit() removes both the last flush()-based and initial CommittedState objects and replaces with a new initial CommittedState.
when Session "rolls back", it "rolls back" the commit/initial-load level CommittedState. the flush-level CommittedStates get discarded.

challenges include, what if the Session itself is inside an enclosing transaction ? thats no problem, the objects within the session are relative to that session.

performance ? yes, problematic from a memory point of view, since now we are saving twice as much data per instance in a multi-flush scenario.

magical/surprises ? i think yes. but with autoflush, it seems to be a surprise the other way too. if a transaction rollback happens, none of your data is in the DB anymore...but with autoflushing sessions, you might get used to thinking that "in the session" means "in the DB"..but then after a rollback(), its not, unless you flush() again. it seems to me that if you have a rollback(), its nicer to not do something magical afterwards.

which leads us to the usual thing, is that we can make this an optional behavior. but im starting to feel a little burdened by all the options we have, just because it makes test coverage much more of a challenge.

Comments (3)