On Tuesday, May 26, 2015 at 11:04:34 PM UTC+5:30, Jonathan Vanasco wrote: > > It is incredibly non-standard to have more than one transaction within a > given request. It is also relatively non-standard to explicitly manage > transactions in the application code. > > I do both of those (the former in very few circumstances) but am in a tiny > minority of users. >
I do the former in cases which involve very long transactions. (Batch uploads and processing. I'm counting batch and background tasks as part of the controller layer here.) > If you decide to handle session state yourself, you will need to address > the intricacies of lazy-loading and collections. If a collection/attribute > is not eager loaded, accessing it in a template will trigger a database > query. If you have already closed the connection or session, sqlalchemy > will reconnect and reload. > I think they were talking about detaching objects from the session so that there's no way it'll reconnect with the database or make any further queries. I'm not saying I'd recommend it as it sounds... extreme. But what do I know? I usually only keep `session.commit()` calls in the controllers. Every other database operation is buried in the models and helper functions. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
