Ok cool.  I actually could write my code to produce exactly that effect
fairly quickly since I was already accessing the mutable object through a
comparable_property on the model.  It was surprising how easy it was
actually... SQLAlchemy really makes things awesome.

We will start looking at moving to SQLAlchemy 0.7.  It will probably be hard
to convince people to move to a "beta" version on production systems
though.  When do you expect 0.7 to leave beta?

I wonder if you could help with one other issue I have occationally observed
that might be related to this.  Sometimes of these mutable objects are None
(myobject.value == None).  These values are non-nullable columns in the
database, and should always be represented as an actual class in logic.  I
have suspected this issue is related to objects being expired (by explicitly
called session.expire()) and then detached from the session.  But it seemed
like SQLAlchemy should always either return a correct value or raise an
exception.  Returning None could result in incorrect behavor for code that
does: if myobject.value: save_the_world().  Does it make sense that this
would be happening?  I think I saw documentation explaining that attribute
values are loaded individually once they are expired?  Could the
resurrecting of state not be happening properly when only loading a single
attribute?

On Fri, Mar 4, 2011 at 2:16 PM, Michael Bayer <mike...@zzzcomputing.com>wrote:

>
> On Mar 4, 2011, at 5:09 PM, Lenza McElrath wrote:
>
> >
> > So there is no way to accomplish this in 0.6?  I was looking at doing it
> the way I describe above, but it is not trivial to figure out which
> model/session a value is attached to.  And I guess it is theoretically
> possible that a value could be connected to two models/sessions.  Definitely
> scared of moving to an untested code... but looks like there are lots of
> improvements in 0.7 that might make it worth it...
>
> well, the on-change event required some less than trivial features so its
> an 0.7 thing.  The best solution of all is to not use mutable types in the
> first place.   I.e. if you need to change a scalar value in place, do
> something like myobject.value = value.mutate(xyz).
>
>
>
> >
> >
> >
> > --
> > 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
> sqlalchemy+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/sqlalchemy?hl=en.
>
> --
> 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
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sqlalchemy?hl=en.
>
>

-- 
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 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Reply via email to