Hello everyone, I'm happy to announce that throughout the summer I'll be officially working on composite fields under the supervision of Andrew Godwin as part of this year's GSoC.
I'll use this thread to post all my weekly status updates regarding this project. This email gives a brief overview of the current status and a rough outline of my plans, as well as a few questions I'd like to raise with the community. So, as far as currently available code goes, there's a github repo containing my work from the GSoC two years ago, which is outdated and incomplete, but still contains a large amount of working code, most of which should be possible to adapt to the current state of Django. The work can be outlined roughly in the following four steps: 1) create a solid implementation of virtual fields 2) refactor ForeignKey/OneToOneField to become virtual fields 3) implement CompositeField 4) make CompositeField work with as many additional parts of Django as possible, including GenericForeignKey and inspectdb 5) possibly implement a mechanism to modify the primary key of a model instance All of the above steps are explained in more detail in the proposal I submitted for the GSoC, available as a gist [1]. Now, for the questions I wanted to raise. ForeignKey customization API ---------------------------- This one is mostly about the extent to which we want the internal implementation of ForeignKey to affect the public API. To keep things backwards compatible, attributes such as db_column or db_index will be just passed to the auto-generated auxiliary field. The question is, do we want to make it possible to specify a custom auxiliary field to a ForeignKey instead of always creating one? A related question, how should it be possible to customize the database columns of composite ForeignKeys? Just make ForeignKey accept a tuple instead of a string? Or just require the user to create the fields (along with a CompositeField) by hand and pass that as the auxiliary field? Any nicer possibility? Either option is rather simple to implement, I just don't really have a strong opinion, although I find both a little bit unpleasant. GenericForeignKey and nontrivial field types -------------------------------------------- As I've indicated in my proposal, just casting any value to a string and then performing a reversible transformation on such strings may work well enough for string and integer database columns, not so much for things like dates, timestamps IP addresses or other similar types. Any ideas on how to make this work? Should I try to extend the backend API to include explicit casts for each nontrivial column type to a string representation equal to the one used by Python? Or should I just document this as unsupported? Updatable primary keys ---------------------- This feature is not directly related to the main objective of this project, which is to implement composite fields. It is just easier for people to get into a situation where this might be required when using composite fields. Full support for this feature would require quite massive changes to the collectors used cascading deletes -- they'd have to be generalized to support cascading updates as well. This would introduce a lot of complexity, obviously. Jeremy Tillman voiced his opinion against this feature in a comment to my proposal. He gives valid arguments -- an update of a primary key would be an expensive operation with potential to kill the performance of any apps doing it. However, the argument that it is easily done with a Model.objects.filter(...).update(...) call is not entirely true as a full implementation of this feature would also cascade. Moreover, it would make this possible in the admin without much hassle. So, seeing that there is at least one voice against this feature, I think it's better to let the community decide if we want it at all. Either way, it's highly unlikely I'd be able to deliver this feature as part of this GSoC, the best I can promise is an initial proof of concept implementation. Michal [1] https://gist.github.com/koniiiik/5408673
signature.asc
Description: Digital signature
