On Dec 22, 2009, at 2:51 PM, Igor Katson wrote: > > I am concerned about the problem of the orm framework using SELECT's a > lot, which can be not used in many cases, when dealing with Postgres > after INSERTs or UPDATEs. > > When using postgresql, I want sqlalchemy, when updating the instance > parameters not to issue additional SELECTS after Session.flush() or > Session.commit(), but to be able to use INSERT/UPDATE...RETURNING, which > will update the values based on the database data. > > As far as I see, there is no such functionality in the mapper or > Session, and I want to extend it for personal use. > > Could you please guide me in the right direction, how to make that?
0.5 supports this using the "postgres_returning" argument to update() and insert(), but the ORM doesn't make use of it. in 0.6, the feature has been generalized using the returning() method on insert() and update(), and the ORM will use it to fetch new primary key identifiers. It does not take effect within the ORM for inline SQL other than primary key identifiers, but you can use an insert() with returning() manually to achieve that effect. The fetch of data after a commit() is based on the expire_on_commit value. If you are using the Session in a concurrent enviornment, the expire-on-commit ensures that current database data is fetched, but you can disable this behavior if you are unconcerned about concurrent transactions modifying rows which are cached in the Session. -- 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.
