Oh wow, have two weeks passed already? I seem to really suck at
email... \-: Anyway, thanks for the comments.
On Fri, Jun 07, 2013 at 03:55:12AM -0700, Anssi Kääriäinen wrote:
> 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.
That's the idea. (-:
> 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...).
As for ImageField, I think its use of the post_init signal is not
really problematic in this regard. Regarding GenericForeignKey, as I
recall, I changed it into a VirtualField and modified Model.__init__
slightly -- first it processes its positional and keyword arguments as
usual and in the end if there are any unprocessed kwargs left, it
checks if any of them correspond to virtual fields and uses setattr on
those. This makes it possible to ditch pre/post_init signal handlers
in GenericForeignKey completely.
> 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...
That's exactly what I've been wondering. Okay then, I'll just document
this as unsupported and look into it only in case I manage to finish
everything else on time. (-;
> I don't see why updatable primary keys would cause big problems for
> performance. Why would these be more expensive that cascading deletes?
It depends on the usage, of course. But I agree that a lot of people
might find that useful without experiencing any significant
performance losses. (IOW, I'm not taking any side on this one. d-: )
> 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 wonder, does the cascading delete code handle non-default to_fields?
This is not clear to me at the moment...
> 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.
Well that escalated quickly... While this is mostly what I had in
mind, seeing it written down like this really makes me want to
reconsider this particular feature.
> 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.
You're probably right, this was a feature I only included in my
proposal for the unlikely case that I'd be finished with the rest of
the work before the end of the program. I'll probably leave it open
and only dig into this if there's nothing else to work on.
Michal
signature.asc
Description: Digital signature
