Alright, cool. All I needed (and I say that rather loosely) was the behavior on columns, anyway. Thanks for the quick response, version .4 has exceeded my expectations for sure :)
On Oct 31, 3:21 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
