As nobody else have responded, here are my opinions... On 2 kesä, 17:22, Michal Petrucha <michal.petru...@ksp.sk> wrote: > 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
Looks like a good plan. Getting CompositeFields, multicolumn primary keys and foreign keys to work as well as possible should of course be priority no.1, all other things are secondary. > 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. I think having a way to manually create the auxilary fields is a good idea. If you need to customize the internal fields for some reason, then having the ability to fully override the fields seems necessary. Be careful about the field ordering, if I recall correctly ImageField and its stored width/height values, and GenericForeignKey have some problems in model.__init__ due to this (need to use pre/post init signals...). > 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? GFKs can be fixed later on. Document this as unsupported if you don't have time to work on this. This means that you can't do JOINs in the database using GenericForeignKeys and multicolumn primary keys. I wonder if this actually works correctly for all possible primary key types in current code... > 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. I don't see why updatable primary keys would cause big problems for performance. Why would these be more expensive that cascading deletes? There is also the problem that foreign keys can be to other columns than primary key, and if we are going to handle foreign key cascades, then these should work, too. I think the best way to do this is to have a model._meta (or maybe primary key field) option "updatable_primary_key=True/False". If updatable_primary_key=True, then store the original primary key into model._state.original_pk in Query.iterator() (and other places that "resurrect" objects from database). This will have a small cost on model initialization and should be avoided for autopk models. On save, check for changed primary key. If changed, then check for cascades. The big problem is what to do for foreign key cascades when to_field isn't the primary key. One option is to check which fields are needed for cascades and store the original values for all of those. Another option is to fetch the old values on save. This will cost an extra database query on save when using cascading foreign keys, but this isn't too bad. By default all foreign keys are on_update=DO_NOTHING, that is cascades aren't handled. My preferred option would be to have DB_CASCADE in addition to CASCADE and DO_NOTHING as on_update options. DB_CASCADE informs the database to create foreign keys as ON UPDATE CASCADE. In my opinion you don't need to handle any of this in the GSoC project. Implementing updatable primary keys, but not foreign key cascades is also possible. Users who want to use updatable primary keys with cascades will need to alter their database schema to use ON UPDATE CASCADE. Handling cascading foreign keys in full will be big enough project for full GSoC, so don't worry about this too much. - Anssi -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
