On Thu, Mar 31, 2011 at 09:54:49AM -0700, Christophe Pettus wrote: > What concerns me about composite fields is that they seem to be a > lot of Python machinery just to accomplish the goal of allowing this > annotation. If they were super-useful in their own right, that > would be one thing, but I'm not sure that I see the utility of them > absent indexes and foreign keys. I'm also bothered, perhaps > excessively, about having two different ways of getting at the same > field in the model just to support this.
Just an observation, there already are two ways of getting at the same
field in case of primary keys...
> So, another proposal:
>
> In the foreign key case, just extending the ForeignKey syntax to
> allow for multiple related fields makes the most sense:
>
> overThere = models.ForeignKey(OtherModel, to_field=('first_name',
> 'last_name', ))
>
> For indexes on the table for the model, include the declaration in
> the Meta class, since that's the obvious place to stick indexing:
>
> class SomeModel:
>
> class Meta:
> primary_key = 'some_field'
> indexes = ['some_field', 'some_other_field', ('field1',
> '-field2', ), ]
> raw_indexes = [ 'some_invariant_function(some_field)' ]
>
> (This was proposed by someone else, and isn't original to me;
> apologies that I can't find the email to give credit.)
>
> Of course, the existing syntax would still work as a shortcut for
> primary_key and indexes.
>
> Thoughts?
One thing I'm missing in this proposal is the behavior of the pk
property. Since the primary key is a tuple, I can't imagine any other
representation in .pk than some flavor of a tuple. And to make things
like SomeModel.objects.get(pk=some_value) possible, we'd still have to
implement most of the functionality of a composite field.
Michal Petrucha
signature.asc
Description: Digital signature
