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.
signature.asc
Description: Digital signature
