>So in the usual case, this would get done implicitly by some middleware, >ie there would be a request scoped unit of work that would be used by >managers unless told otherwise, and it would call save() if the request >works, or it would discard it on an exception.
Yes, that sounds good to me. >This way, individual items would no longer need to have a .save method. >They would always be saved by the unit of work. I think I still would keep the object .save() method - just to make the simple case still as simple as the current code is - the programmer shouldn't need to worry about units of work if he doesn't need transactions. Could this possibly done with the event system, where objects post events that are catched by default UnitOfWork objects, while managers are allowed to hook into those events and mask them from the default UnitOfWork and pass them on to their explicitly given UnitOfWork? This could scale nicely: - the simplest case will just use objects as before, posting to one request-bound UnitOfWork. This gives you the same as we currently have. - you can have managers that have different connections, but just use the default UnitOfWork for those connections (managed by some middleware). This would give you the possibility for easy multiple connections. - or you can have explicit UnitOfWork objects to manually manage all your transaction needs. This gives you full control. Events have the benefit of being dynamically scoped, so it could be easier to hook into the event chain - objects would just post events on .save(), as would managers, UnitOfWork would be the consumers. But I don't know wether Loui (or PyDispatch) allows to mask events from other receivers, so maybe it's not the right way to do (I did something similar once with exceptions in Python, as exceptions are the most useful dynamically scoped core language element available). The idea would be to have a chain of responsibility for handling DB IO and to delegate that from object to manager to unit-of-work, with everyone in the chaing having the opportunity to divert flow of data and with sensible default handlers that behave much like Django behaves now. bye, Georg
