This sounds exciting. I can't wait for this to land in master. Thanks, Michal!
On Sunday, June 2, 2013 10:22:36 AM UTC-4, Michal Petrucha wrote: > > 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 > -- 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. For more options, visit https://groups.google.com/groups/opt_out.
