On Sep 9, 2011, at 10:39 AM, Russ wrote:
> Thanks for clarifying with a full answer!
>
> > This should not be construed to mean that you should only use the ORM
> > with SERIALIZABLE isolation. It's instead just something to be aware of.
> > You can of course expire any object or individual attribute at any time. In
> > this case, if you were to add s2.expire(s2c1) on line 88, you'd then get the
> > "222" value on the next check as it would emit a SELECT.
>
> But it does seem to emit a select! The output surrounding the line 88 query
> is below:
>
> Querying s2 again (whose transaction is still open) to see what it gets for
> c1...
> SQL >> SELECT counter.id AS counter_id, counter.name AS counter_name,
> counter.count AS counter_count
> SQL >> FROM counter
> SQL >> WHERE counter.name = %(name_1)s
> SQL >> {'name_1': 'C1'}
> s2 gets C1.count = 1
>
> ... so what were those SQL emmissions about? They did not seem to arrive at
> the database (based on the result, anyway).
when you say query(Class).filter(<criterion>).one(), that always emits SQL.
It's an open-ended query, and SQLalhcemy doesn't know that s2c1 is the object
which corresponds to the SQL you're about to emit. When the row comes back,
it then extracts the primary key from the incoming row, determines that
identity is already in the identity map and is unexpired, and the row is
skipped (that's the disconnect here - incoming rows are not used if the
existing identity exists and is unexpired).
if OTOH you had said query(Class).get(pk), that would pull from the identity
map directly and not even hit the DB in this case.
--
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.
