Sorry for chiming in so late. I very much like the goals of this effort, particularly bringing clarity to some of the internal APIs. Some related points for your consideration:
* Would the rows matched vs. updated issue be resolved or clarified in this effort [1]? * It seems like the work I had started to expose accurate update/delete counts [2], and further provide the capability for conditional updates and deletes [3] would be more clearly done on the basis of such a refactor. Does that seem accurate to you or will it not make much of a difference there? Thanks. -- Steven [1] https://code.djangoproject.com/ticket/17435 [2] https://code.djangoproject.com/ticket/16891 [3] https://code.djangoproject.com/ticket/16549 On Thu, Jun 14, 2012 at 3:58 AM, Anssi Kääriäinen <anssi.kaariai...@thl.fi>wrote: > On 14 kesä, 10:59, Aymeric Augustin > <aymeric.augus...@polytechnique.org> wrote: > > Hello Anssi, > > > > I'm familiar with the topic since I tried to review some of your > > refactoring patches (before you gained the ability to commit them > > yourself). > > > > I'm convinced that this refactoring is useful, because it is likely to > > fix some bugs, especially in features that were added to the ORM long > > after its original design, and it will make ongoing maintenance > > easier. > > > > It's also very difficult to review and I'm afraid I may not be able to > > help a lot, besides sanity-checking patches. Anyway, ask loudly for > > reviews when you have patches ready, and I'll try to join the effort. > > Thanks for all for the offers for reviews. > > I think I will go forward with the following plan: > - For small issues I will create a ticket + pull request and > announce that I am going to commit the request. I will wait for couple > of days and commit if no objections or requests for more time are > raised. > - For medium issues I will ask for a review and wait for one. > - For bigger issues (db schemas, deepcopy() vs. clone()) there need > to be some form of consensus that the approach is in fact correct. > > Lets see how the above works. If it doesn't, then lets figure out some > other way. A branch for "orm-next" could work also... > > I will post a short request here on django-developers, and then detail > the request in the ticket. > > For now the big issue needing review is the django.utils.tree/add_q > refactor. https://code.djangoproject.com/ticket/17000#comment:7 and > https://github.com/akaariai/django/commits/refactor_utils_tree > > I would like to get the qs deepcopy/clone() thingy moved forward or > closed as wontfix. Luckily this is a well separated issue from rest of > queryset refactor, so there is no hurry for this one: > https://code.djangoproject.com/ticket/16759#comment:33 > > - Anssi > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
