On Thursday, January 13, 2011 10:29:10 PM UTC-5, Michael Bayer wrote: > > So you're looking to do a write-through cache here, i.e. write the DB, then > write the value straight to the cache. I think if you were to say > session.flush(), which emits the SQL, then detach all the objects using > session.expunge(), they're no longer affected by subsequent session > operations, then session.commit(), commits the transaction, that would > produce the effect you're looking for. >
Perfect... flush()->expunge()->commit() does exactly what I want. Now to learn about expunge cascades to tune it up! > Is there any clean way to set expire_on_commit behaviour at a per-object > level? It seems to be all or nothing at the moment. > > Bizarrely, this question had never been asked before, until about five > hours ago. That happens quite often, for some reason. For that user I > suggested using SessionExtension.after_commit() to re-implement expiration > on subsets of objects only, though you'd need some plumbing to indicate what > objects get the expiration - perhaps you'd set some attribute on them. I > think the flush()->expunge()->commit() idea is easier. > Ack - sorry about missing that topic. I'm glad I did as the expunge route is easier as you say. It is great to keep the after_commit() in mind, though. Well "un-expire" is just hitting the object's attributes so it loads back > again, assuming you're looking to not have the extra SELECT. If you were to > SELECT all the rows at once in a new query() that also would unexpire all > the existing objects it hit within the one result set, if that's useful > information. > You are correct, I'm limiting my SELECTs as I've got a few spots where tables are heavily trafficked and every SELECT hurts. I've used joinedload a lot to cut down on selects as well. I used to specify lazy loads in the relationship definition, but joined loads at the query is more explicit and cuts down on excess data loading for times when it really isn't needed. A bit off topic, but there you go. Given how fast and great your response is, I also have to send some kudos your way. Not only is SQLAlchemy a great piece of software and extremely useful, but your attentiveness to this group and obvious passion for the project is truly amazing. I have no clue where you find the time for it, but I assure you it is greatly appreciated! Russ -- 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.
