On Nov 19, 8:14 pm, Michael Bayer <[email protected]> wrote: > The ORM uses attribute set events to flag changes. It then uses the > "previous" value, if present, to determine if a change has taken place at > flush time, and if so issues an UPDATE. If "previous" is not present, in > most cases we don't need to load it, and the UPDATE is unconditional. > > With a mutable structure where the user expects inline changes to take place, > the task is more complex, since there is no "set" event. We have no choice > but to immediately copy the structure on load so that we can detect this > change. An eventual solution to this would be that we instrument the > mutable structure itself to flag change events on occurrence, but this is a > very involved enhancement. >
Ah, this is why ZODB made you use PersistentList objects and the like: http://www.zodb.org/documentation/guide/modules.html > so here is the magic word, "deferred". mutable + deferred has never been > considered. Ticket #1976 is added to evaluate if we can skip the "load" > when the col is deferred and the value wasn't loaded. Seems to work so far > but needs more tests and this would probably be in 0.7. Cool. > Note however that this "SELECT" is nowheres near the central inefficiency of > a mutable type. The central inefficiency is that we need to scan the whole > session on every flush and compare every mutable value to its old one. Your > usage of "deferred" doesn't help that too much since if you are modifying the > item in place, we still have to store it twice and compare on every flush. > "mutable" is not a flag you'd ever see within 100 yards of any of my > applications until we work out a way to instrument the values. I didn't quite pick up on that sentiment in the docs - have created #1979 to add a few headings there. I'll follow the advice given there with setting the mutable flag to false. Thanks again! Eoghan -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
