Let me apologize first for using JKM as an alias to the whole core
team. I guess the problem here is that adding this feature really
entail changes in too many areas. It would be nice if you and the
other core team members can set a direction for changes on this issue.
The various patches suggested in those previous threads all seem to
fix one problem while giving rise to another somewhere else. So having
a direction that fundamentally address this issue i think would be a
On the other hand, i have to say that I am not too familiar with this
open source style of working on a project. At my company, issues like
this that span across multiple sub sections usually can only be
resolved by management stepping in. From what I've read here in the
user/dev mailing list, it seems that the only reason that this can't
be resolved is due to lack of leadership from above. (Totalitarian
states usually are pretty efficient in execution...military, another
example...perhaps sqlalchemy could be a third example with MB being
the strong leader). Anyway, i guess by seeing your email I've already
achieved quite a bit. Simply having you recognizing such a problem
again after 2 years i think it's already going somewhere. Perhaps in a
few days we will see some patches coming in.
I am glad to see that you are willing to help. I will try to
contribute if i can although i don't do this by trade.
Oh yeah, as for the tone...I was pretty disappointed not to see this
proposal being included in your list earlier today (it's like Santa
had forgotten you the day of christmas) and it somehow seemed to me
that this list is a final list for 1.1 release.
Plus, if you had a chance to look at the type of databases that I have
to deal with by day, you will see why this is so important to me.
Composite primary is the only non-issue issue at work; you gotta see
the kind of lack of constraints, primary key, proper privilege, tests/
verification/process, bizarre division of schemas and all the other
database craziness at my work, you would understand my frustration.
The django orm + admin/admindocs, with all these beautiful scaffolding/
self-documenting/constraints generating/best practice imposing
goodness, would be a great way to rectify some of that craziness. But
no, it's not too usable because it doesn't handle composite pk (ok,
hacking it would make some parts available--it is working for me right
now, but imagine what a Lumbergh-from Office Space- type of manager
would say...and imagine what all the Java IT guys would say). And
finally, i don't think my frustration is particular to my company/
group, everyone i know to who work in a similar enterprise environment
in the silicone valley seems to have the exact same problems (unless
your company is a hip facebook/web app development company). Leaving
people like us behind I think is a huge missed opportunity for
Post by Jacob Kaplan-Moss
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
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
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.
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
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.
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to firstname.lastname@example.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en