Hi! >coupling. one question about the the implementation design, i guess i'm >not clear why a stack is needed at all? unless there is some sort of >mixing between different modes is expected on the same request, which i >think would best to avoid due to the subleties and complexities of the >stack transaction blocks interactions, ie. any automatic blocks in the >stack prior to a managed will have their lifecycle dictated by it, as >opposed to the semantic notion in the docs of tying to the >request/response cycle, basically requiring global knowledge of the
Not everybody will use the django code in webapps - if you write batch programs, you need a way to do transaction handling, too. And the decorators already "stack" - you might have the transaction middlware active, so your transactions are bound to request/response, but you want to use the commit_manually decorator on some functions where you want to controll transactions manually. >regarding the actual implementation, it would be nice to see the core >transaction manager api pluggable by encompassing the commit/rollback >function implementations into a private global instance (or at least a Please provide some sample code how you think this would look like. It's easier to talk about code than about ideas, as ideas can easily be misunderstood (or not understood), while code is just that: code. :-) bye, Georg
