Also keep in mind that work has been done, but as I haven't had a lot of spare time to continue it (attempt #3?). It's a very complex problem as well, like Jacob mentioned. You have to deal w/ the legacy use of single primary keys, as well as the new composites. While I almost have a fully functioning version (barring ForeignKey support) it's still going to take a little bit.
On Sun, Nov 16, 2008 at 4:19 PM, Jacob Kaplan-Moss < [EMAIL PROTECTED]> wrote: > > 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 > > > > -- David Cramer Director of Technology iBegin http://www.ibegin.com/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
