The limitation of Django's single database, single connection paradigm is one that I have been recently grappling with. In a recent discussion in the users group, I went so far as to call it an "unfortunate" design decision. While I agree that the label I chose is purely a subjective value call, I do think that the design decision nonetheless has long term implications for the future adoption and positioning of Django with respect to the brave new world of Python web frameworks. The idea that a web application is tied explicitly to a single database via a single connection (and for some database engines implicitly a single schema) will have a profound impact on the types of situations that Django finds itself in. For me to suggest how the framework should be designed or what types of use cases it should be targeted for is ludicrous, but I would encourage the developers to make this limitation more visible in the documentation and perhaps to highlight the scenarios where Django will work and in which scenarios the framework might not be an appropriate choice.
I came to Django initially from a hobbyist standpoint - picked it up based on recommendations and based on personal evaluation that the development philosophies and community embody what I like to see. For throwing experimental sites together, prototyping, creating personal tools and utilities I think that Django is a tremendous and powerful framework. I am aware that Django is in use in some high traffic sites and clearly it is up to the task. Being excited about using a framework that makes development more fun, I naturally made the decision to bring Django into my job. I'd love to use it to create back office tools and applications, and in time I would like to use it for public facing web sites once everyone is comfortable with its existence in our organization. This is where I quickly ran into trouble. For example, I'd like to expose data from legacy databases via basic CRUD-type interfaces. The problem is that our Sr. Data Architect who has 20+ years experience (more than 10 years my senior), doesn't want his transactional or warehouse databases "cluttered" with framework meta tables. Frankly, I agree with his reasoning and its simply a battle that I won't even put in the effort to try to win. In another scenario I would like to do what foob described above, allow the user authentication to also specify the database user credentials. Again this is simply not "possible" with the out-of-the- box framework. Now, it may be possible with simple tweak or a pattern, but as of yet I haven't seen anything "official" that allows for this kind of flexibility. I have begun poking around the code in search of a non-intrusive way to allow for specifying connections on a per session or even per request basis. As Max pointed out, there are both security and overhead costs associated with increasing flexibility with respect to database connections. I do greatly appreciate that the developers take security and performance to heart and don't necessarily integrate a feature just because it might save someone a few lines of code. There is a fine line here and my belief is that this debate will become a focal point for the make-or-break future acceptance of Django into the web development community - especially in the enterprise space. I don't want to just assume that Max's point of view accurately or completely represents the sentiments of the development team, but based on other discussions I have seen I feel like this may be the case. As a professional software engineer, I understand that every language, tool, command, and program that I use carries with it some trade off - performance vs. ease of use, rapid creation vs. flexibility/customization, size vs. speed, etc. It is up to me to be cognizant of what those trade offs are and to understand how they affect what I am creating. Think about choosing an automobile. One can choose from trucks, SUVs, station wagons, hybrids, sedans, town cars, etc. Each of those automobiles carries a trade off when evaluated across different categories. The point is I can choose to drive a Geo Metro down the freeway in order to reduce fuel consumption, knowing that if someone inadvertently bumps me it will take the jaws-of-life to get me out of the wreckage (no offense to Geo Metro owners). It seems like the Django group is taking a Microsoft- ish philosophy here - "we've decided for you what your database and access policies should be. If you have a need to communicate with more than one database or schema, or to dynamically specify the user credentials for a database connection, simply redesign your database schema(s) and access policies before continuing." When taking a stance like this, I think it would be fair to those getting started with or evaluating Django for the first time to specify that: Django may not be a good choice in the following scenarios: * You want to interface with a legacy database and for policy or permissions reasons are not able to create tables on that database. * Your application communicates with multiple databases or schemas. For example, transactional data lives in one database, reference data lives in another database, administrative data lives in a different schema and archive/audit data lives in yet another database. * Your application uses multiple database connection credentials. For example users are associated with database accounts and you would like to have database access take place under these accounts so that database access policies can be managed within the database rather than one or more external applications. Another example is using different accounts for read/write access or on a per table basis. While it may be the collective opinion of the developers that the above examples only represent extreme or rare cases, my personal feeling is that these types of scenarios are really not that uncommon. In enterprise scenarios or even scenarios where just scaling is the focus, I believe that logical and sound reasons can be made for all of the above. Going back to the car analogy, those of us who take driving seriously (probably most of us to some relative degree) understand that a car is indeed a powerful machine and its use requires some learning ahead of time, practice, respect for safety, and an assumption of physical conditions met: reasonable eyesight, use of an arm and a leg, alertness, sobriety. Does that mean that everyone who chooses to drive an automobile meets those conditions? No. We can't force safe practice upon everyone but we can strongly encourage it. In the end it is the individual's responsibility to follow through on their own education and well being. When I see responses like "on the big map of Django features is not a good idea and a good way to singe people's fingers. Furthermore, for the majority of cases this sort of database authentication is overkill and bad for performance..." it makes me a little sad. I would like to believe that between the collective 30 years of experience between myself and our sr. data architect we can decide for ourselves if the overhead of a connection per request on an intranet application that might make one request per minute is a valid use case. If our data architect is comfortable with allowing an intranet application to specify the connection based on the application user's credentials why shouldn't we be "allowed" to operate our application in that manner? So at the end of my rant here, the conclusion is that I feel like I've outlined why Django will not work well in enterprise settings based on my experience with what I'd like to say are common design decisions. It could very well be that the framework is not and never will be intended to be used in enterprise settings. No problem. I just think it would be helpful to either clarify that this is the case or at least provide some sort of road map for when parties interested in adopting Django can check back in to see if it will meet their needs. Cheers -Brian On May 9, 1:47 am, foobarmus <[EMAIL PROTECTED]> wrote: > Thanks for the response, Max. It's very to the point. Much > appreciated. > > > Yes. The conventional wisdom that everyone "should know" is never to > > use such web to database pass-through authentication for anything > > bigger than an intranet application behind corporate firewalls/VPNs. > > > There are huge security concerns with any sort of pass-through > > authentication, and putting a pass-through authentication into a > > public-facing website is just asking for crackers to sit there and > > pound your site for any and every SQL injection they can think of. > > Pass-through authentication *can* be just as devastating as allowing > > direct remote connections to your database. > > I can't argue this point until I've read more about it, but can't they > do this anyway? Also, If the accounts you're passing through have the > correct levels of access to objects in the database, they shouldn't be > able to be dangerously abused, or is there something else I'm missing? > > > If you are willing to _meticulously_ audit every security implication > > then good luck. > > Maybe I am, I dunno yet > > > For a general purpose framework like Django adding support for this > > without big flashing warning signs and a general "HERE BE DRAGONS" on > > the big map of Django features is not a good idea and a good way to > > singe people's fingers. Furthermore, for the majority of cases this > > sort of database authentication is overkill and bad for performance > > (instead of maintaining one long session with the database per thread > > the framework has to back out and deal with database sessions per > > request which just reeks of early (pre-auto-session-magic) bad PHP > > applications). > > Ok, I understand, Thanks for the clarification. > > > Unfortunately it's a bit late and I can't scrounge up some good links > > on the subject (hopefully someone else can follow up with those), but > > I hope that I at least have illustrated at least the conventional > > wisdom with a few smudges of reasoning... > > If anyone can furnish me with some good links about this, please do. > > Regards, > > foob --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
