Re: [sqlalchemy] Unnecessary SQL emitted after a commit to get a PK?

2011-01-13 Thread Russ
On Wednesday, January 12, 2011 2:16:00 PM UTC-5, Michael Bayer wrote:

 Suppose a concurrent thread or process deleted your row in a new 
 transaction and committed it, or didn't even commit yet hence locked the 
 row, in between the time you said commit() and later attempted to access the 
 attributes of the row.  That's the rationale in a nutshell.


Thanks, this make sense.  For my purposes (where business logic ensures no 
post-commit shenanigans) on this one I can just snag the id after a 
pre-commit flush() and that will be fine.

For my issues with object detachment I'll post another topic.

-- 
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.



[sqlalchemy] Unnecessary SQL emitted after a commit to get a PK?

2011-01-12 Thread Russell Warren
Check this code out:
http://python.pastebin.com/kMV611z7

In there I generate an object instance, add it to a session, then commit it.
 I then try and access the id attribute (autoincrementing PK), which results
in SQL being emitted... but the emitted SQL has the id value in it already!
 Is there a reason for this?  Is it just that it commit() expires all
attributes, so *any* attribute access results in a refresh?  I think I'm
missing something in my understanding of this.  The PK is clearly kept for
the resulting query.

And one more thing... In the same code you can see I'm trying to access an
instance property after the instance has been added to a session, and the
session has been closed.  Is there any way to make the last-known attributes
of an instance available after the previously associated ORM session is
gone?  I thought that expunging did this, but it seems not.

Thanks,
Russ

-- 
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.



Re: [sqlalchemy] Unnecessary SQL emitted after a commit to get a PK?

2011-01-12 Thread Michael Bayer
Suppose a concurrent thread or process deleted your row in a new transaction 
and committed it, or didn't even commit yet hence locked the row, in between 
the time you said commit() and later attempted to access the attributes of the 
row.  That's the rationale in a nutshell.

see expire_on_commit=False as well as Session.commit() for further detail:

http://www.sqlalchemy.org/docs/orm/session.html#committing
http://www.sqlalchemy.org/docs/orm/session.html#sqlalchemy.orm.session.Session.commit

To reassociate detached objects with a session, use Session.add() or 
Session.merge().  Detachment is described at 
http://www.sqlalchemy.org/docs/orm/session.html#quickie-intro-to-object-states .


On Jan 12, 2011, at 2:02 PM, Russell Warren wrote:

 Check this code out:
 http://python.pastebin.com/kMV611z7
 
 In there I generate an object instance, add it to a session, then commit it.  
 I then try and access the id attribute (autoincrementing PK), which results 
 in SQL being emitted... but the emitted SQL has the id value in it already!  
 Is there a reason for this?  Is it just that it commit() expires all 
 attributes, so any attribute access results in a refresh?  I think I'm 
 missing something in my understanding of this.  The PK is clearly kept for 
 the resulting query.
 
 And one more thing... In the same code you can see I'm trying to access an 
 instance property after the instance has been added to a session, and the 
 session has been closed.  Is there any way to make the last-known attributes 
 of an instance available after the previously associated ORM session is gone? 
  I thought that expunging did this, but it seems not.
 
 Thanks,
 Russ
 
 
 -- 
 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.

-- 
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.