OK. for object-holding relations, i.e. using relation(), the same rules apply - use dynamic relations or lazy=None. theres events that occur when you assign to a relation-holding attribute, like backreferences, cascades, and setting "orphan" flags, so in that case the "load" of the former value is fairly important...while it may be able to be improved, disabling the behavior for just scalar relation () attributes (i.e. many-to-one) still fails lots of tests so this adjustment would require a little bit of effort to get right.
for column-based attributes, the load of the "deferred" value when assigning is not super-critical; while it does get "compared" to the new version, if you're assigning to the attribute its probably more the "right thing" to just unconditionally write the new value without bothering to load the old value. so ive made that change in r3695. if you try out the trunk your regular column-deferred attributes shouldn't be loading the old value when you assign a new value. On Oct 31, 2007, at 2:36 PM, Michael Bayer wrote: > > > actually, let me think some more about this, i might be able to > adjust this behavior for column-based attributes. > > On Oct 31, 2007, at 2:28 PM, Michael Bayer wrote: > >> >> >> the reason it fetches the existing value is to do a comparison, so it >> knows whether or not to flush that attribute (or for collections, to >> determine specifically whats changed). if youre dealing with a >> relation(), you can use a dynamic relation which will eliminate any >> loading when setting (see the docs), or setting lazy=None will also >> eliminate any loading from occuring. for a regular column attribute, >> theres no "noload" option for that currently, youd have to issue an >> UPDATE manually. column-level noloads are conceivably possible as a >> feature but id probably express it as "unconditonal-write", since >> youd still want a get() operation to access the value, correct ? >> >> On Oct 31, 2007, at 12:47 PM, Chris M wrote: >> >>> >>> I have a table with a deferred column. I want to fetch an object >>> from >>> the database and update this column, but have no use for the actual >>> value of it. However, it seems when I change the value of the column >>> it first fetches the value for it and then sets it before doing the >>> update. Is there any way to stop this behavior? It's expensive >>> especially for updating columns that are relations, as it fetches >>> the >>> deferred column, then the row it references, then sets it before >>> updating. >>> >>> >>>> >> >> >>> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
