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
-~----------~----~----~----~------~----~------~--~---

Reply via email to