Hi Michal, This looks like a good starting point for a proposal (not to mention that we don't doubt that you know about the problem area here!) - a few comments:
- I'd like a bit more detail on some of your timeline points, in particular what the introspection parts and primary key updates are (personal bias, I suspect) - I'd like more details on what's been holding it back since GSOC 2011, and how this GSOC is going to help serve those Still, I like the general idea. You've mentioned tests and docs too. And I really, really want to land this feature! Andrew On Fri, Apr 19, 2013 at 10:17 PM, Michal Petrucha <[email protected]>wrote: > Hello, > > as I promised a week ago, I'm posting a draft of my proposal. It is > far from complete, specifically, it does not contain technical details > on how things are going to be implemented. I'll try to fill these in > as soon as possible, although I wrote more on most of them in my > previous emails to this list. The most important thing is that it > contains a timeline and a description of possible fallbacks. > > The proposal is accessible as a public gist [1] where it will be > updated in the future, I'm posting the full text here as well for > convenience. > > Have a nice weekend. > > Michal > > [1] https://gist.github.com/koniiiik/5408673 > > > Composite Fields, vol. 2 > """""""""""""""""""""""" > > Aim of this project > =================== > > Since I started working on this two years ago, I managed (with the > help of a few people) to get most of the hard work done. The biggest > part that I didn't get around to implementing was support in the ORM > for multi-column joins. This has, however, been implemented recently > by Jeremy Tiller and Anssi, which means there are only a few things > left to be done. > > First of all, the code sitting in my github repo is badly out of date, > which means it needs to be updated to the current state of master. > While I'm at it, I also want to clean up the revision history to get > it as close to a state where it could be just reviewed and merged > directly as possible. > > Beside this, there are only the juicier features left that we > initially wanted to leave unsupported and get back to them later. > Those are the following (in no particular order): > > - ``GenericForeignKey`` support for ``CompositeField`` > - more intelligent handling of ``__in`` lookups > - database instrospection and ``inspectdb`` > - detection of a change of the primary key in model instances > > Timeline > ======== > > Our exam period starts on May 20. and ends on June 28., which means > that I can't guarantee I will be able to fully dedicate myself to the > project for the first two weeks, however, if nothing goes wrong, I > should be able to pass all exams before June 17. > > Also, I intend to go to EuroPython, which means the first week of July > won't be as fruitful as the others, but otherwise I'm ready to work > full time on the project. > > Week 1 (Jun 17. - Jun 23.) > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > - porting the required virtual field changes, like a ``VirtualField`` > class and ``django.db.models.options`` changes > - revisiting the documentation I wrote two years ago to reflect the > evolution this project has gone through > > Week 2 (Jun 24. - Jun 30.) > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > - porting the virtual ``ForeignKey`` patchset on top of master to get > most of the functionality right > > Week 3 (Jul 1. - Jul 7.) > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > - EuroPython 2013, Florence > - I intend to spend the full two days of sprints working on this but I > can't promise much more during this week. > - running through the tests and fixing those that need updating, > ironing out the remaining wrinkles > > Week 4 (Jul 8. - Jul 14.) > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > - basic ``CompositeField`` functionality, ``CompositeValue`` and > descriptor protocol > > Week 5 (Jul 15. - Jul 21.) > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > - ``db_index``, ``unique`` and ``primary_key`` for ``CompositeField`` > - backend-dependent SQL for ``__in`` lookups on ``CompositeField`` > > Week 6 (Jul 22. - Jul 28.) > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > - the few patches required to make admin work with composite primary > keys > > Week 7 (Jul 29. - Aug 4.) > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > - composite ``ForeignKey``: basic functionality, descriptors, database > JOINs > > Week 8 (Aug 5. - Aug 11.) > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > - composite ``ForeignKey``: customization of auxiliary fields, > adapting ``ModelForms`` and the admin in case it is necessary > > Week 9 (Aug 12. - Aug 18.) > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > - ``GenericForeignKey`` and ``GenericRelation`` support > > Week 10 (Aug 19. - Aug 25.) > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > - database introspection: create composite fields where necessary > > Week 11 (Aug 26. - Sep 1.) > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > - database introspection: composite ``ForeignKey`` > > Week 12 (Sep 2. - Sep 8.) > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > - better handling of modifications to primary keys: detecting the fact > and issuing an appropriate DB query > > Week 13 (Sep 9. - Sep 15.) > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > - revision log cleanup > - better handling of modifications to primary keys: cascading primary > key updates > > Week 14 (Sep 16. - Sep 22.) > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > - this is after the suggested “soft pencils down” deadline, therefore > I'll keep this week as a reserve > > Deliverables and fallbacks > ========================== > > As the timeline shows, the first few weeks will be dedicated to > internal refactors of the relationship handling parts of the ORM, > which means the outcome won't be entirely evident or useful by itself. > By the end of the sixth week, I expect the refactor of ``ForeignKey`` > to be stable for concrete target fields. Also, the non-relationship > part of ``CompositeField`` functionality should be ported on top of > this. > > Next, there is support for composite foreign keys. This is the core of > the work and the absolute minimum I want to squeeze out of this > project to consider it at least partially successful. > > All the features that appear later in the timeline are optional, > ordered by the priority with which I would like to implement them. In > the unlikely case of extreme difficulties with the previous parts of > this project some (or possibly all) of them may be left out. > -- 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.
