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

Reply via email to