On Tue, Mar 5, 2013 at 4:42 AM, Aymeric Augustin < aymeric.augus...@polytechnique.org> 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. > > 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. > > -- > Aymeric. Don't forget about doubling the number of tests that need to be run for each database backend to ensure both old and new work as expected. Supporting multiple APIs simultaneously seems like it would be very tedious, error prone, and add additional constraints on how the overall transaction management can be improved, assuming it's even possible to do both simultaneously in a stable way. The superset API would be less clean and would add more support overhead for all of the backends, not just MySQL. This question may have an obvious answer, but it has yet to be asked. What is the likelihood that people will actually benefit from being able to flip a setting to convert from old to new transaction management, instead of just stopping on Django 1.5 until they are ready to make the transition to whatever backwards incompatible changes exist in Django 1.6? If there is a new superset API, then anyone using a 3rd party database backend will be left behind until the backend gets around to implementing the new API. To give a little perspective as a 3rd party database backend maintainer (django-mssql), I'd probably just drop support of the old behavior as soon as I made the changes to support the new. Even if the superset API should theoretically just work for both, there will be more testing, support issues, and code complexity to ensure both APIs work as expected. I don't really have the time or motivation to support a transition state that guarantees additional API changes (removal) in the future. >From reading this thread, I also feel like the arguments in favor of the parallel old and new support has not really been justified. It's a huge body of work for an small edge case. The arguments also seem to provide a strong justification for revisiting the idea of moving database backends out of the core. I don't want to sidetrack this thread, I'll start a new thread momentarily, but I think the idea is relevant for the current discussion and should help decide which way to proceed. Regards, Michael Manfre -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
