On 12/7/06, Dennis Muhlestein <[EMAIL PROTECTED]> wrote: > > This is more of a best practice question: > > I find having the framework manage the database session for you OK 95% > of the time. What do you do in the other 5% of the time? > > Example 1: I have certain credit card processing methods that require > commits to the database before and after the card is processed. > Example 2: I have some methods that require no database interaction. > (So why create a session? .. also.. how much overhead is there in > creating the session?) > > Anyone have any best practice ideas for situations like this? >
I just wrote different controller classes that stuck the right (or no) db connection in the context for each request. I have one for read-only, one for read/write, and one that doesn't hit the db at all. To do this I had to write my own transaction management stuff of course. I eventually switched from TG to Pylons for that app, but I'm using the same strategy with that framework. -bob --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
