On Aug 19, 2005, at 12:40 PM, Martin Maney wrote:
The specific problems I recall offhand were transactions (which are being worked on, or maybe have been finished by now) and multi-column keys, which no one seemed to be interested in at all. Maybe the problem is that I don't try to beat the drum, mentioning the issue so often that it gets paid attention to.
Transactions will be in 1.0 -- it'll actually be fairly easy to implement, we just need to actually do it. Now that you mention it I do recall the discussion in IRC about multi-column keys; I've probably forgotten about it as no one ever filed a ticket. I've taken care of that: http://code.djangoproject.com/ticket/373.
I don't really know how much work it would be to support multiple- column keys; my gut feeling is that it'll be pretty complicated to integrate with the admin interface. What I mean is this: given a model with a standard integer primary key, the admin URL is something like ``/app/module/14/``. It's also simple if the object has a non- integer key; something like ``/app/module/foo/``. However, for a model with a multiple key, what's the URL? If something as simple as URL resolution in the admin is going to cause problems, imagine all the other places where it will break...
For that matter, do MySQL and sqlite support multiple column primary keys?
I wonder why you can't just "fake" it by declaring one of the keys to be primary in Django and adding a unique constraint to the model. You'd have to do without the auto-generated SQL that Django gives you, but if you're smart enough to know how and why to use multiple primary keys, you can probably write the schema by hand.
On the other hand, if you still want real multiple primary key support -- which Django really *should* do -- I'd be happy to work with you on a patch; email me off-list if you'd like to give it a shot.
Jacob
