On Feb 27, 2008, at 12:00 PM, Judah De Paula wrote:

err you can *try* but that might be a hard road to travel. when i did the copy-on-write refactoring i added a huge amount of unit tests to that whole system since it became more particular about how things are done..what decisions to make when theres no key present in committed_state, when theres no key in __dict__ but present in committed_state, etc. Also you're still dealing with internal things so you're not going to be stable.

Another issue with allowing direct __dict__ access is that you arent issuing any of the other attribute events SA needs. The "cascade" functionality, which does things like saves "B" when you say A.b = B, also drives off of events, as well as bidirectional relationships (i.e. backrefs) working themselves out. On the get side the whole ability to lazy load expired/deferred/unloaded attributes and collections drives off of the event system.

If you could take a look at the most recent thing I've done in the new branch and let me know if that meets your needs, that would be helpful. It seems like not, since you are dealing with C code that unconditionally writes straight to __dict__ and you cant use the normal event routes. Its possible you could fire off the normal SA events in the method illustrated in the example, which ultimately write to __dict__ anyway and it would just be a "double write" scenario, but not ultimately harmful.