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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
