Originally reported by: Michael Bayer (Bitbucket: zzzeek, GitHub: zzzeek)
why are we tracking every list append operation so closely with HistoryArraySet ? why all the switchy stuff with ScalarProperty ? why not just, load the instance from the DB, say "commit()", all the attributes get copied to another object that hangs off the instance. attribute access is then largely unfettered (although backrefs still must fire, cascade operations might be nice to continue, and lazy load/expires must still occur...so cant do away with instrumentation altogether). when you flush(), then we look at the "copied" object and come up with added()/unchanged()/deleted() based on that. hibernate does it more this way.
the two issues are: attribute instrumentation is too complicated and attribute instrumentation is too slow. this ones not going to go away until a real rethink occurs.
Originally reported by: Michael Bayer (Bitbucket: zzzeek, GitHub: zzzeek)
why are we tracking every list append operation so closely with HistoryArraySet ? why all the switchy stuff with ScalarProperty ? why not just, load the instance from the DB, say "commit()", all the attributes get copied to another object that hangs off the instance. attribute access is then largely unfettered (although backrefs still must fire, cascade operations might be nice to continue, and lazy load/expires must still occur...so cant do away with instrumentation altogether). when you flush(), then we look at the "copied" object and come up with added()/unchanged()/deleted() based on that. hibernate does it more this way.
the two issues are: attribute instrumentation is too complicated and attribute instrumentation is too slow. this ones not going to go away until a real rethink occurs.