I tried to incorporate the remarks into my proposal and I'm posting the updated parts.
As usual, the full version is still available at http://people.ksp.sk/~johnny64/GSoC-full-proposal Retrieval and assignment ~~~~~~~~~~~~~~~~~~~~~~~~ Jacob has actually already provided a skeleton of the code that takes care of this as seen in [1]. I'll only summarize the behaviour in a brief example of my own. class SomeModel(models.Model): first_field = models.IntegerField() second_field = models.CharField(max_length=100) composite = models.CompositeField(first_field, second_field) >>> instance = new SomeModel(first_field=47, second_field="some string") >>> instance.composite CompositeObject(first_field=47, second_field='some string') >>> instance.composite.first_field 47 >>> instance.composite[1] 'some string' >>> instance.composite = (74, "other string") >>> instance.first_field, instance.second_field (74, 'other string') Accessing the field attribute will create a CompositeObject instance which will behave like a tuple but also with direct access to enclosed field values via appropriately named attributes. Assignment will be possible using any iterable. The order of the values in the iterable will have to be the same as the order in which undelying fields have been specified to the CompositeField. QuerySet filtering ~~~~~~~~~~~~~~~~~~ [...] Afterwards the handling inside Query is pretty straightforward. For CompositeFields (and virtual fields in general) there is no value to be used in the where node, the extra_filters are responsible for all filtering, but since the filter should apply to a single object even after join traversals, the aliases will be set up while handling the "root" filter and then reused for each one of the extra_filters. This way of extending the extra_filters mechanism will allow the field class to create conjunctions of atomic conditions. This is sufficient for the "__exact" lookup type which will be implemented. Of the other lookup types, the only one that looks reasonable is "__in". This will, however, have to be represented as a disjunction of multiple "__exact" conditions since not all database backends support tuple construction inside expressions. Therefore this lookup type will be left out of this project as the mechanism would need much more work to make it possible. GenericForeignKeys ~~~~~~~~~~~~~~~~~~ Even though the admin uses the contenttypes framework to log the history of actions, it turns out proper handling on the admin side will make things work without the need to modify GenericForeignKey code at all. This is thanks to the fact that the admin uses only the ContentType field and handles the relations on its own. Making sure the unquoting function recreates the whole CompositeObjects where necessary should suffice. At a later stage, however, GenericForeignKeys could also be improved to support composite primary keys. Using the same quoting solution as in the admin could work in theory, although it would only allow fields capable of storing arbitrary strings to be usable for object_id storage. This has been left out of the scope of this project, though. Estimates and timeline ---------------------- 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 support for composite primary keys week 6 (Jun 27. - Jul 3.): - full support in the admin 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 week 10 (Jul 25. - Jul 31.): - support for ForeignKey relationship traversals week 11 (Aug 1. - Aug 7.): - making sure OneToOne and ManyToMany work as well week 12 (Aug 8. - Aug 14.): - writing even more tests for the relationships - finishing any missing documentation ----> pencils down
signature.asc
Description: Digital signature
