Malcolm Tredinnick wrote: > As I mentioned to Collin at the code sprint in Portland, I think it'd be > a good idea to make sure we expose the ability to turn on auto-commit, > but I don't really like making it the default. In any case, providing > the ability that's can be controlled via, for example, a setting is > certainly the first step here. That's pretty independent of the whatever > the default might end up being. That's really the improvement needed to > #3460 at the moment -- separating adding functionality from changing the > default.
...and then repeated the point in a later mail, so I think that we should try to write a patch which a) makes 3460 a configuration option as suggested, and b) supports transactions on top of the autocommit connection when explicitly requested (3460 currently doesn't, so parts of the test suite currently fail when it is applied). I'd appreciate people's thoughts on the following proposal of how to do this. Particularly Malcolm, Jack and Collin since they seem the main contributors to date. 1) Mechanism to make it a configuration option Various people on the 3460 ticket tracker have suggested using [6064], but that isn't yet in trunk, and also wasn't generally agreed on the tracker (e.g. does not allow custom Python). So, let's not do that. We need two things - a way to create the backend in autocommit mode: I suggest a flag 'native_autocommit' for DATABASE_OPTIONS - a way for the running Django to tell that the backend is in autocommit mode: I suggest a flag 'uses_native_autocommit' for BaseDatabaseFeatures In both cases I'm deliberately choosing mechanisms and words so that other backends could also later be changed to support an autocommit mode. 2) Transaction support when explicitly requested The current 3640 patch leaves a Django which does not support any transaction behavior other than autocommit (leading to various test suite failures). The problem is that django/db/transaction.py also needs to be rewritten to actually create transactions (i.e. issue SQL BEGIN/COMMIT or BEGIN/ROLLBACK) on top of the connection when the user explicitly requests them. This is also a better and more general solution that the current hack to one specific case in loaddata, which could then also be removed. We'll essentially need two independent versions of transaction.py - the existing one for when Django runs on top of an implicit transaction, and a new one which actually creates transactions for when it doesn't. Implementations would be very different, but the interface and semantics can be identical, I think (except for rollback_unless_managed(), which cannot be supported, so would have to be removed from both versions and uses rewritten in some other form). I propose that we write the new version and test 'uses_native_autocommit' at the start of each function to decide which implementation to use. Malcolm: - You previously wrote: "This proposed change is a bit more complicated than the patches in #3460" - I do agree, but I think this is the only way to get 3460 to pass the transaction parts of the test suite! Do you see a simpler alternative? - You also wrote "The fact that none of the many patches on that ticket even touch save/update/delete handling has to be an error" - again I agree, but think that all of the required changes to save/ update/delete handling can be isolated away into transaction.py, as above. Do you see other problems? As I say, I'd appreciate people thoughts on this proposal - would this leave us with a patch for 3460 which will be accepted into trunk? Do people see problems/improvements to my proposal? This will be quite a bit of code for someone to write, so I'd like the design clear and agreed first. Cheers, Richard. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" 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/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
