On Thu, 2011-05-19 at 17:14 -0700, Alec Munro wrote: > So I have a few pylons and pyramid applications under my belt, almost > all using SQLAlchemy. So far, I have gravitated towards doing all the > SQLAlchemy work as part of the models themselves. Occasionally, this > has led to design decisions that I otherwise wouldn't have made, like > having code that affects the workflow of a process on a model. But > otherwise, all my SQLAlchemy imports are already with the models, and > I'm a bit squeamish about doing database work elsewhere, in case I > were to prematurely close a transaction or something like that. > > As an example of what I am talking about, most of my code looks like > this: > > #views.py > def add_to_context(context, request): > context.add(request.params["foo"] > > #models.py > Class Context: > children = relation(...) > > def add(self, child): > session = DBSession() > self.children.append(child) > session.flush() > Transaction.close() > > Instead of this: > #views.py > def add_to_context(context, request): > session = DBSession() > context.children.append(request.params["foo"]) > session.flush() > Transaction.close() > > #models.py > Class Context: > children = relation(...) > > > > Any thoughts/best practices around this? >
Why do you need to do Transaction.close()? - C -- You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en.
