Hi Jacob, 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 better approach.
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 django. Frank On Nov 16, 2: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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
