> On Sun, 2008-07-27 at 15:55 -0700, David Cramer wrote:
> > I'm to the point in a project where I *need* composite primary keys,
> > not using them would be a bit retarded and wasteful. So, I'm going to
> > write up the patch.

> > Here's how I was doing it before QS-RF:

> > - MyModel._meta.pk would return a tuple if it had multiple
> > - MyModel._meta.pks would always return a tuple

> It's be nice to do away with the need for the "pks" attribute, since it
> provides more than one way to do something. Yes, it means that sometimes
> you might need to test whether pk is a list or tuple, but that should be
> relatively rare.

> > - pk='hello' would still work as it does now
> > - pk=('hello,') would work
> > - pk=dict(field='hello') would work (to allow for unordered pk lists)
> > - Composite primary keys would be created simply by passing
> > primary_key=True as an argument on more than one field in your model.

> This won't work nicely, since it doesn't allow you to specify the order
> that will be used when assigning. Instead, for multi-column primary
> keys, I'd suggest specifying them as an attribute on Meta:

>        class Meta:
>           primary_keys = ('username', 'location')

> The order given there is the order used to specify them in assignments.
> Having to reorder fields in a model to do that otherwise (if you only
> used the primary_key attribute on the field) sets a kind of dangerous
> precedence, since it says that might be an okay approach, except nothing
> else can do it because ordering is then reserved for primary keys. We
> already have a few issues that arise out of managers being treated
> differently according to their order of declaration and it would be nice
> to avoid that in this new feature.

> > Anyone have any feedback, or started working on any code?

> I've got some code that is going to land in the next week (before the
> sprint, most likely) that adds most of the necessary support for
> multicolumn fields. This is primarily to fix a few bugs with generic
> relations in a non-specific way (it will work for all similar fields).
> The stuff I'd done on multi-pk work -- which I'm not going to finish
> before 1.0, because it's not that critical, so you're not duplicating
> anything I'm doing there -- seemed to work nicely on top of that. So you
> might want to keep an eye out for that. The main case where it's
> applicable is when somebody does filter(foo__pk=(1, 2, 3)) because you
> can no longer just replace "pk" with the name of the real attribute,
> instead you have to treat it as multiple columns.

> Regards,
> Malcolm