On 11/16/05, Jonathan LaCour <[EMAIL PROTECTED]> wrote: > > On Nov 16, 2005, at 9:23 AM, Kevin Dangoor wrote: > > How would you, in an ideal world, see the API as being different with > > events or "better filtering"? Always best to start with the ideal and > > then make tradeoffs as needed. > > At least in the case of transactions, it would be nice if it wasn't a > transaction per controller method, but a transaction per *request*, > which isn't really handled by the decorator case. I think it _could_ > be handled better by a filter-like approach.
For the potentially many methods that are just reading data, you don't really want a transaction, and decorators are a nice way to configure where you want the transaction. Now that i think about it, transactions are already maintained on the thread level so it should be fairly straightforward to keep reusing the same transaction. As Roman points out, there may be times where you want to use nested transactions (just make sure you're not using sqlite). So the trick is finding the best defaults and an easy way to diverge from the default. Kevin
