Thanks for the reply, yes it is a mutable type:
import jsonpickle
class JsonType(types.MutableType, types.TypeDecorator):
impl = types.Unicode
def process_bind_param(self, value, engine):
return unicode(jsonpickle.encode(value))
def process_result_value(self, value, engine):
if value:
return jsonpickle.decode(value)
else:
return {}
I guess I can't disable the mutability flag?
>From reading up on mutability:
>http://www.sqlalchemy.org/docs/core/types.html#sqlalchemy.types.MutableType
I think I understand why it's required to lookup the previous value;
so that the orm can decide whether to construct an update query for
the instance when a flush event occurs (is that correct?).
Should there be a shortcut for column assignment, so that rather than
looking up the previous value, the column is flagged as 'mutated'?
If that was the case you'd get a spurious update if the old_value
happens to be equal to the new_value, but shouldn't it be up to the
app programmer to do this check?
It seems to me that there's an unnecessary lookup of the old value
when it is being replaced wholesale, which I cannot stop even though
I've marked the column as deferred.
All the best,
Eoghan
On Nov 4, 1:47 pm, Michael Bayer <mike...@zzzcomputing.com> wrote:
> is this a mutable type like PickleType? the previous value should not be
> loaded otherwise (assuming at least a recent 0.5 or 0.6 version). If so, the
> mutability flag should be disabled.
>
> On Nov 4, 2010, at 7:05 AM, Eoghan Murray wrote:
>
>
>
> > I have the following:
>
> > objs =
> > MyTable.query.options(defer(Table.potentially_very_long_str_column)).all()
> > for obj in objs:
> > obj.potentially_very_long_str_column = ''
>
> > At the moment, I'm seeing the assignment in the loop issue the `SELECT
> > potentially_very_long_str_column`, even though that column will be
> > overwritten.
>
> > I pdb'd this down to orm/state.py::InstanceState.modified_event()
> > where the previous value is stored in self.committed_state
> > I'm ignorant as to what self.committed_state is used for, but maybe
> > rather than evaluating 'previous' value, it could be further deferred
> > until it is needed? This is assuming that self.committed_state will
> > only be used up until the session is flushed (at which time the
> > previous value would be lost)..
>
> > At the moment, is there any other way of writing to a column without
> > first reading it using the orm?
> > Haven't checked, but I assume sql.expression.update doesn't have
> > this behaviour..
>
> > Cheers!
>
> > Eoghan
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
