I am surely guilty of muddling the conversation from the specific case of multi-DB to the more general and more perilous case of dynamic connections. In fact I'm using the multi-db branch now for a non- critical app and it works just dandy. Also I know of someone who is working on updating that branch to the head revision so in my mind there is not even much to debate with respect to multi-db (static connection per) functionality.
Now that I've slaughtered more horses than at a bad day at the Kentucky Derby, time to get down to business :) In response to your perspective, one of the great things about a well done MVC is that it should be modular enough to swap out the individual components without any major ramifications to the rest of the overall system. I do like SQLAlchemy and after I spend a little more time assessing the pros and cons of fiddling with the current models+managers+connection I'll evaluate the consequences of using an alternative ORM altogether. Of course, there is nothing that prevents one from using external projects anyway since you just need to deliver a dictionary to the template renderer but as you said automatic admin would be lost and I imagine the generic views functionality would need to be retrofitted with an adapter of some sort. Thanks for the advice! Have a great weekend Cheers -Brian On May 11, 11:00 am, Vinay Sajip <[EMAIL PROTECTED]> wrote: > On May 11, 6:32 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > > > user: Hi I'd like to be able to connect to multiple databases and/or > > specify connections dynamically for my Django app. > > That wasn't what the original poster said: > > "I'm managing a programming team that's developing a web app in > python. > I'd like to be using Django but can't at the moment because one of the > things we are doing is driving the application user into the database > connection, so that we can implement access control at database level. > > I would like some opinions on this practice." > > This doesn't appear to be the the same thing as the multi-db branch, > which is trying to provide support for access to multiple databases, > rather than multiple database-authenticated connections into a single > database. So the flogging is being applied to the wrong dead horse, > God rest its soul ;-) > > Anyway, as I see it, even if you don't Django's models (whose > persistence in a relational DB leads to those things that people here > are finding constraining, such as single DB and single DB user) you > still get an excellent framework with clean URLs, a simple dispatch > mechanism, some nifty middleware, and support for the presentation > layer through the templating system. Use these parts of Django with > e.g. a SQLAlchemy (or just plain DB-API) layer which you can use to > fine tune any database scheme you like. Sure, you won't get the ready- > made admin interface, but development is often about trade-offs, > right? Django can't be all things to all people. Certainly, multi-db > and multiple database-authenticated connections are not the common > case, at least in my experience (and that's not a value judgement > about these approaches). > > Regards, > > Vinay Sajip --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
