Frank Liu wrote: > I guess i thought the core developers would've added this proposal to > the list (judging from the title of this thread). > > Regardless, even if this had been added, it would've been given a -1 > anyway, judging from the readiness of this feature. > > More importantly though, my gripe about this is that if you go through > a search for this feature, you would see entries from 2006. Over the > last 2 years, there were multiple threads on this and yet nothing was > really done to it. How many time have we seen attempts at integrating > sqlalchemy and django? And really what features did people intend to > add? It's really obvious (at least to me) that it's for the multi db > support and composite primary key (I mean exactly what else does > sqlalchemy do better, ok more backends, what else?). Why don't people > get this? > Whether people "get it" or not, proposing the integration of an entirely different database front-end (it would be unfair to characterize SQLAlchemy as an ORM: it's actually quite a lot more than that) is almost certainly way too radical a step for a point release. It may well be way too radical a step for release 2. OK, so it's an important use case for you, but surely you can see that puts you in the minority, and the development team have to think about the majority first. > And let me correct myself a bit. It's not that no one has done > anything, it's just that people have been only writing bits and pieces > of hacks here and there to patch the flaws, but this problem has > proven to be more difficult than just patches. For example, there are > numerous suggestions in this thread in the API of the model. However, > SO WHAT? does it matter? I like both. Both have merits. THEN WHAT? > what about the admin layer, what this and that relationship, what > about these recursive thing. Almost every one of these composite key > threads had been stalled somewhere either in admin or the model api > that nothing substantial was done. (usually a thread like this goes on > a few 10s of exchanges and finally left cold...just like this one). > > And I think this is not the developers' fault. I think fundamentally > there are 2 reasons for this: 1. the original design of the orm is not > up to the task so that extending it proved to be too difficult. As > have been mentioned in numerous places, the orm is one place where > loose coupling should be taken with a grain of salt. > > Well whether this is true or not you can surely see that some kind of radical change would be needed for you to have your pony. Or would you disagree? > 2 lack of leadership. To deal with this difficult situation, it is > important to have the big guys like JKM (ok i don't know any other > obvious names, but JKM here represent the core team) to say, "ok now > let's address the orm issues and this has to be done before release of > 1.1" and so the smart minds of everyone else will start churning AND > making those opinionated decisions that django is so famous for (which > most of time is really brilliant). But no, JKM never has any interest > in this because either he doesn't work in an enterprise environment > anymore (because he's too successful unlike the rest of us still > working in an Office Space envrionement) or django had seen tremendous > growth even without it, why bother. (what i mean to say here is JKM, > please post a note on the main site and mobilize your goons to address > this issue. I am pretty sure it would be done before i go to work > tomorrow). > > I think this not only mischaracterizes Jacob's leadership of the project, it also mischaracterizes the relationship between Jacob and the other core developers. Further, it does so in a somewhat unpleasant way which I hope you will retract, as none of the core developer I've come across could be described as "Jacob's goons". We don't need this unpleasantness on a list which is intended to discuss the future of a large software framework, and it can serve no useful purpose. > Finally, don't get me wrong, i love django and python. It is simply > the best language and best web framework out there for me (where > enterprise reporting fit beautifully into a micro-app type of > architecture instead of pylons or turbogears full blown application > architecture for each report). But the orm really drives me crazy. Of > course we all wrote custom managers, and overriding save to deal with > the composite key short comings, but come on, there's gotta be some > more pythonic (battery-included, there's only 1 obvious way) way of > dealing with this. > > Well, you've certainly expanded on your frustration. To say that the required changes could be made in less than 24 hours is a breathtaking oversimplification, however. If you believe it, then roll your own sleeves up and you could surely have it done by the end of the week.
Open source, remember? This means that leadership is a bit like herding cats. I think you just took a good shot at pissing the cats off. regards Steve --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
