On Tuesday 05 March 2013, Aymeric Augustin wrote: > > In practice, this would mean: > - Define "hook points" that are a superset the old and the new APIs. > - Re-implement the current transaction management with these "hook points" > (hard, because the intended behavior of the dirty flag isn't clear). > - Implement the new transaction management with these "hook points" > (hard, because that prevents using Python's context manager abstraction, > which maps exactly to atomic blocks and guarantees that the exit method > is always called). > - Add checks to prevent invalid operations when mixing the old and new > APIs, this is extremely difficult to get right when there are many hook > points. > - Provide simple guidelines on how the old and new APIs may be > mixed. > - Ensure that the old API can be trivially removed, because the > author of the new code may not be there in two years. >
I assume "new" and "old" APIs refer to commit_on_success vs. atomic (just making sure I got you right)? > This looks possible, but not in the amount of time I'm able to spend > volunteering for Django. If someone wants to implement this, I'll put my > branch on hold. Otherwise, I'll propose it for inclusion into core. I couldn't ask for more, Shai. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
