On Thu, Apr 7, 2011 at 2:51 AM, Michal Petrucha <michal.petru...@ksp.sk> wrote: > GSoC 2011 Proposal: Composite Fields > ====================================
Hi Michal, This looks to be a fairly solid proposal. You've done a lot of detailed research, and while I'm almost completely certain you'll find some gremlin lurking underneath some dark corner of the code, you appear to have a good grasp on the scope of the problem you're proposing to solve. A couple of quick comments: > Relationship fields > ~~~~~~~~~~~~~~~~~~~ > > This turns out to be, not too surprisingly, the toughest problem. The fact > that related fields are spread across about fifteen different classes, > most of which are quite nontrivial, makes the whole bundle pretty fragile, > which means the changes have to be made carefully not to break anything. Feel free to do some housekeeping while you're in there :-) The internal structure of foreign keys and m2ms isn't officially stable API, so you have some liberty to do some cleanup. > This infrastructure will allow reimplementing the GenericForeignKey as a > CompositeField at a later stage. Thanks to the modifications in the > joining code it should also be possible to implement bidirectional generic > relationship traversal in QuerySet filters. This is, however, out of scope > of this project. This, for me, is ultimately one of the biggest areas for gain. Adding the new features of composite FKs and PKs will certainly be a big benefit, cleaning up the special case handling for Generic Foreign Keys will be a much bigger architectural win. I appreciate that you have to draw the line somewhere; but I suspect that you may be faced with the need to modify an interface in a way that will make it easier to handle CompositeFields, but breaks the existing implementation of Generic Keys. If this happens, updating GenericKeys may be an inevitable consequence. > As I will have quite a few exams at school throughout June, I won't be > able to commit myself fully to the project for the first month and will > spend approximately 20 hours per week during this period. By the end of > the exam period, however, I intend to have sped up to about 30-35 hours > per week. I don't have any problem with this; it's an unfortunate consequence of European school terms. However, we've historically encouraged applicants to stretch the rules a little bit, and start early on their project so they can compensate for at least some of the time they lose during exams. > The proposed timeline is as follows: > > week 1 (May 23. - May 29.): > - basic CompositeField implementation with assignment and retrieval > - documentation for the new field type API > > week 2 (May 30. - Jun 5.): > - creation of indexes on the database > - unique conditions checking regression tests > > week 3 (Jun 6. - Jun 12.): > - query code refactoring to make it possible to support the required > extra_filters > - lookups by CompositeFields > > week 4 (Jun 13. - Jun 19.): > - creation of a composite primary key > - more tests and taking care of any missing/forgotten documentation so far > > week 5 (Jun 20. - Jun 26.): > - ModelForms and GFK support for composite primary keys > > week 6 (Jun 27. - Jul 3.): > - full support in the admin Weeks 5 and 6 seem particularly ambitious -- not completely impossible, mind; just very ambitious. > week 7 (Jul 4. - Jul 10.): > - fixing any documentation discrepancies and making sure everything is > tested thoroughly > - exploring the related fields in detail and working up a detailed plan > for the following changes > > ----> midterm > By the time midterm evaluation arrives, everything except for > relationship fields should be in production-ready state. > > week 8 (Jul 11. - Jul 17.): > - implementing composite primary key support in all the > RelatedObjectDescriptors > > week 9 (Jul 18. - Jul 24.): > - query joins refactoring > - support for ForeignKey relationship traversals Again -- another ambitious week. > week 10 (Jul 25. - Jul 31.): > - making sure OneToOne and ManyToMany work as well > > weeks 11&12 (Aug 1. - Aug 14.): > - writing even more tests for the relationships > - finishing any missing documentation > > ----> pencils down > > As can be seen from the proposed timeline, there is a separation between > the part that leads up to admin support for composite primary keys and the > relationship part. In my opinion the first part is more likely to be used > in practice than the second part so the main emphasis will be put on it in > case I discover unexpected difficulties. However, looking at the timeline > broken down into small parts I'm confident all proposed features should be > possible in the given time. Given the ambitious nature of this project, it's good that you've considered the worst case scenario, and you have a plan for handling it. Just to clarify -- my understanding is that if the project only got as far as it's midterm goals, it would be possible to define a CompositeKey (primary or otherwise) on a model, but you wouldn't be able to query across that composite. Have I understood correctly? Yours, Russ Magee %-) -- 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.
