Hi Frank -- It's hard for me to figure out how to answer this: if you've got a problem with my leadership skills, I don't really see how anything I say makes much of a difference. Frankly, your tone is completely inappropriate and I feel I'm enforcing absurdly out-of-line behavior simply by responding.
However, I'm just going to ignore those parts of your post and focus on the real question. Support for composite keys has indeed been requested before. In fact, it's ticket #373; opened about three years ago! On July 20th, 2006, I commented: """ [He]re are the issues [...] that would need to be solved to make this work: There's three basic problems in dealing with composite primary keys in Django. The first is that a number of APIs use "obj._meta.pk" to access the primary key field (for example, to do "pk=whatever" lookups). A composite PK implementation would need to emulate this in some way to avoid breaking everything. Second, a number of things use (content_type_id, object_pk) tuples to refer to some object -- look at the comment framework, or the admin log API. Again, a composite PK system would need to somehow not break this. Finally, there's the issue of admin URLs; they're of the form "/app_label/module_name/pk/"; there would need to be a way to map URLs to objects in the absence of a primary key. """ (http://code.djangoproject.com/ticket/373#comment:3) That's a pretty clear list, and it's been sitting out there for over two years. I've pointed folks at that comment any number of times since then, and at some point someone expanded somewhat into a wiki page (http://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys) that could serve as a simple spec. And yet three years on I've yet to see a patch appear on #373. Yes, this gets asked for time and time again, but nobody seems to want it enough to write even a *partial* fix. Why should this be? I think the main reason is that the lack of the feature is quite easy to work around in most cases. So most people who could fix it just don't feel like it's worth the time and move on. Somehow, despite the strum und drang there isn't really enough energy here to prompt anyone to work up a patch. Patches are the unit of currency in this community. With very few exceptions, every one of Django's thousands of commits began life as a patch posted by someone in the community. We committers can be a lot more effective when we review and integrate other peoples' patches — I can review a dozen patches from a dozen different people in the time it takes me to fix one bug on my own — so by necessity we have to rely on our community. If there's a feature you need, implement it. If you can't figure out where to start, ask — I'm on #django-dev during most of the work week, and I'd be happy to help anyone who wants to hack on this feature. If you don't want to or can't implement it yourself, there's a legion of options available ranging from asking around for help to organizing a team to contracting someone qualified. Finally, please keep in mind that the feature list we're drafting right now isn't set it stone. Anything that gets finished between now and the feature freeze date for 1.1 (2/15/09) is a candidate for inclusion. We develop these feature lists to help people figure out what to work on; nobody's gonna tell anyone not to scratch their own itch — that's what open source is all about. Jacob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
