On 5/30/06, Arnar Birgisson <[EMAIL PROTECTED]> wrote: > > Now, the question is, should we create a session at the start of the > request and store it in some globally accessible variable and flush it > on completion of the request, or should we leave it up to the user to > create her own sessions? > > The former is more like they way TG does it today with 0.1, and more > like the SQLObject way. However, I would personally prefer the latter, > since it gives the programmer more control over sessions and > transaction stuff. He might want to open sessions to multiple engines, > create several independed transactions etc. all within the scope of > one CP request. To me, the latter also seems more in tune with > SQLAlchemy 0.2. Whaty do you think?
The reason we added implciit transactions was because people were ending up with a lot of the same boilerplate code to start and finish up transactions in their methods. Yes, people *might* want to open sessions to multiple engines. But, that's not the common case. We should optimize the API for the common case, and then make sure that the less common case is possible. So, implicit transactions should be the default. Probably doing as you suggest: put the session on the request or something like that. There could be a config variable to turn that off globally. Additionally, there could be an option to expose() to not do transactions (though that feels a bit ugly, particularly given that you can have multiple expose decorators now). The right place to start is probably putting the session in the request and having a config option to turn off automatic transactions. Kevin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears -~----------~----~----~----~------~----~------~--~---
