> Given that this is also possible, it seems like there are several > different ways to do this off the top of my head: > > 1. WSGI middleware (I think) > 2. CherryPy filters > 3. SQLObject modifications > 4. Decorators > 5. Some mixture of the above > > What is the best way? I have no idea, but I am intrigued by option > #3, because I thought it might be hard, and it would take into > account the actual use of the model objects automatically... of > course it doesn't take into account anything that happens directly > against the DB not through SQLObject... > > That being said, I really don't know what the best option is. Kevin, > have you decided on a direction to take here? How can I help? > > > There are some open caching issues with transactions as well, that > > require some thinking about what has to be expired when. And, > > really, transactions could probably make more use of caching than > > they currently do. > > I am very interested in the direction that you are planning on > taking, and how I can help.
I would not go with CherryPy filters. They are not the right place to do so IMO. CherryPy filters are point cuts around the HTTP request/response processing. Therefore, those filters have no knowledge of the stack built on top of it. Transactions mean nothing to CP. Thus CP can't help you the right way to use them. Besides, future versions of CP (the 3 branch) might as well change all of that and thus TG would be stuck with CP 2.x I'd say that you should always keep in mind that CP is only dealing with HTTP requests/responses so don't try to overload CP with higher level features :) The decorator seem to be the best place per se because it doesn't involve a complex machinery as would to use a WSGI middleware solution (which would by-pass CP I guess). As for the SQLObject one, I don't know enough of it to say if it could be the right place. Hope this helped a bit. - Sylvain ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
