Hey Russ, As always your response is sound, candid, and well thought out. You're either nimble with your typing or you put in a little block of time to compose that so thanks!
Just a few quick points: 1. I see now that there is a definite intention maintain a particular profile for the framework and for the purpose you described Django fulfills its role exceptionally. 2. I realize that my point of view is something that's not high on the radar of either the general user community or the developers necessarily. Let's face it, I'm exceptionally selfish sometimes. I just want to use Django at work and for many of my particular use cases I need the capabilities I described in a stable and easy to maintain manner. So I just wanted to rally any support and you're right the voices are a little meek. I had to try because you just never know when someone out there might already have a little piece of code handy that they just never thought of or bothered to make available. I will gladly share any of my findings and solutions with the community. Also carole.ziegler is going to be working on merging the MDB branch so things will definitely be happening :) 3. Misleading is not the right term. I don't have any great ideas about exactly what should be changed or added to the existing documentation to be honest. I just think it would be "fair" to point out - maybe in the tutorials section or somewhere newcomers often visit - the single DB paradigm. For example, throw in a little note/ caution/info section with something to the effect of "Django by default only supports a single database connection to a single database across the scope of the entire application. For some users this raises concerns as it may not fit the access and/or authentication policies of their particular scenario. Django is targeted toward clean room development of new web applications and for the purpose that Django is primarily intended, supporting more flexible connection options would introduce unnecessary complexity into the framework. There are community supported solutions available for these usage patterns. <link multidb branch wiki, snippets, etc.> For more information about the philosophy behind Django's database connection operation <link>" 4. One thing you helped me realize is that maybe the best story isn't how these features integrate naturally into the framework but rather what are the options for moving Django apps out of the "clean room". After all, we all want to see our little baby apps grow into big and mature apps someday. The book does a great job on the deployment chapter IMHO and as some of the flexible db usage patterns emerge the story will be slightly even more compelling! (says me :)) Cheers -Brian On May 9, 5:56 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On 5/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > (quite a lot) :-) > > Hi Brian > > The primary design use case for Django development is clean room > development of a new web based application. This is what it was > originally designed for, and there is plenty of evidence around to > suggest that it is more than capable of supporting heavy web server > and database loads (there was a message on the users list today about > surviving a slashdotting [1] - if that doesn't count as > enterprise-grade load, I don't know what does). > > We have introduced a few features along the way to make it easier to > integrate with some legacy databases. However, using a large, > pre-existing database as the starting point for a Django application > has never been a primary design concern, and I am not aware of > anywhere on the Django website that suggests that this is the case. > There are references to function arguments that can be used to > integrate with legacy tables, but the overwhelming focus of the > documentation is on how to use Django to write new tables. If you feel > we are being misleading somewhere on the website, let us know and > we'll clarify the appropriate comments. > > We're always open to making things better. Your message suggests three > areas where you feel Django is deficient: > > 1) Integration with legacy databases that prevent creating new tables > 2) Connection to multiple databases > 3) Per-user database connection credentials > > To my reading, (1) is a subset of (2) - if you can support multiple > databases, you can support putting all your legacy data tables on one > database, and putting your management tables in another. > > (2) is already the subject of a branch. > > I don't see any reason why (3) couldn't be implemented, too. > Obviously, there would be the need to document the potential security > risks, and we wouldn't want to make the default 'single connection' > approach for the common use case any harder to use. If you can come up > with a viable design, feel free to suggest it. > > However, the biggest hurdle is people to do the work. It's fine to > have great ideas about what is wrong and how it should be fixed - but > ultimately, someone has to write the code. > > Despite your protestations about how essential "enterprise" features > are, there just doesn't appear to be _that_ much interest in them in > the Django community. We get many more requests about schema > evolution, unicode support, and customizability on the admin interface > than we ever get for multiple database support. This doesn't mean that > multiple database support isn't important - just that for our current > user base, it isn't _as_ important as many other features. > > Remember, Django is a volunteer Open Source project. That means that > whoever writes the code gets what they want. The core developers are > concentrating on the features that they need or see as important (for > me, this is testing tools). If you _really_ want "enterprise" > features, either volunteer and write them, or volunteer to pay > somebody to implement them. > > [1]http://www.cogitooptimus.com/2007/02/11/wow-we-made-it/ > > Yours, > Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
