Perhaps I should have given more specific info about the project. It's not a CMS, or one of these "happy apps" that just have a database because it's cool to have one.
It's a tightly modelled, configurable, business administration tool. If used in a business of significant size, I would expect and hope that a DBA was employed to administer the database. Many of the tables will contain information that is restricted (sometimes with different scope for readability and editablility) to various roles which are mapped to individuals or groups in the organisation. It is likely that other apps will connect to the database as well... For example if a business wanted to develop a custom CRM that leveraged some of the data in my database, I would welcome and possibly even encourage that approach. Almost invariably, my application will be implemented within a firewalled corporate network (regardless of the architecture of any custom apps that are messing with my data). I say almost, because I'd like to support web use as an option. In that case I may enforce a different connection architecture to allay security concerns. If someone from Django is interested in talking to me about development of functionality that could make its use plausible in my scenario, my organisation may be willing to cough up some cash, or directly lend some development resources for the purpose. Foob PS. I'm still interested in reading more about the security flaws of web to database pass-through authentication. If anyone has any good links, don't hang back. On May 10, 8:56 am, "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 -~----------~----~----~----~------~----~------~--~---
