"While I'm not saying that multiple DB-level users and DB-level access
controls are the wrong solution, I would ask up-front what specific
real-world problem is being solved by this, and whether it really is
the best solution."
I think what you're overlooking is that in some cases the issue of
whether its the "best solution" is irrelevant. If the database is
already in production or the policies are already set or controlled by
an external entity, then debating the merits of the single DB, single
connection philosophy is pointless.
Since we're all into historical anecdotes :) lets take a look at the
COM/CORBA school of thought. Coming from a MS background, I'm more
familiar with the COM saga personally. There was a time when a lot of
people thought COM was the way forward and DCOM (distributed COM) was
going to lead the way to distributed object oriented engineering
bliss. MS spent a lot of money and resources pursuing this technology
and if you look at the internals of many of the Windows bits and
pieces, COM is very prevalent even today. In time COM was displaced
by the combo of .NET and web services technologies such as SOAP/XML-
RPC. That does not however mean that COM-based software magically
went away. In fact many companies in the business world that built
their software on top of COM are still rolling out new features on top
of that same infrastructure.
Now we can sit here and pooh-pooh their use of COM all day but the
moment we need to interface with their platform all the bitching in
the world will not provide a single ounce of problem solving. It
simply doesn't change the fact that while something may have been
designed and implemented according to state of the art at that moment,
in five or ten years the capabilities and techniques available across
the landscape of software engineering will render those previous
designs useless or antiquated or even silly (as you point out with the
password change policy example). And who is to say what is the "best"
state of the art solution? One of the beauties of software
engineering to me is that for a given requirement many different
looking solutions can be adequate. For example, 3 developers are
tasked with improving the performance of a web application:
-Developer A, who just got back from a LAMP Scaling and Architecture
conference, decides to buy another server box and cluster the database
across 2 servers.
-Developer B, who just got back from a MySQL conference, realizes that
they can categorize the data access for the application into distinct
categories and then apply different storage engines to the tables that
fall into each category. Overall a day or two of work.
-Developer C, who is really more of a DBA, relies on their years of
experience fine tuning and optimizing DB performance to both move some
of the business logic into sprocs and functions where it will execute
on top blazingly fast compiled code rather than interpreted Python and
also creates a separate read-only logical database that provides an
extra 10-15% boost due to the large amount of reference data pulled on
many requests.
Based on hardware costs, developer salary costs, company policies,
project timelines, legal issues, and the many other factors that
affect our day-to-day activities, who made the best decision and who
made the worst decision? I will state that since each developer chose
a path that was comfortable to them given their specific engineering
experience, they all made good decisions. The caveat is that they all
need to understand what the trade offs of their particular decision
meant to the larger and future scope of the application.
There are 2 main themes that I've taken away from the recent
discussions surrounding these issues. The first is that for the time
being the collective developer standpoint is that Django is being
positioned (primarily? mostly?) as a framework targeting early stage
web application development. The framework is very well suited for
this role IMHO. I continue to encourage the development team to
gather the many sound and logical arguments that have been presented
in favor the of the single DB, single connection (SDB/SC if I may)
paradigm and at least put this into a section somewhere on the site
and/or book documentation. I think that this is valuable, educational
information for users. In particular, for users who are creating new
applications it might be beneficial to some to understand the
potential negative consequences as you have laid out so that they
don't invest time going down the road of planning certain aspects of
their design at the database level. In effect you are simply arming
people who have decided to invest time in learning the framework with
information that will help them get the best use of out the framework
in accordance with what the developers intend it to be. That would
seem to be a win/win situation. This is not of course to imply that
Django is not well suited to scaling up to high-traffic applications.
It has obviously proved itself in that regard and people will find
that as long as they stay within the SDB/SC mold they will still have
many viable options for scaling their application as described in the
book's deployment chapter.
The second emerging theme is that at this time Django is not
necessarily well suited to be used to build on top of existing
databases or to extend existing applications. I feel like to some
degree the arguments being put forth for SDBSC come from a slightly
idealized view that all Django uses are for creating applications from
scratch against data models that are yet to be created. There are a
lot of "well in the real world" this and "well that's just bad design"
thats that are being put forth to bolster your arguments. Frankly
I've said previously that I completely buy into your reasoning for why
SDBSC presents a secure and sane path toward application development.
(some may disagree but that's their issue) Its just that there are
some of us who recognized Django for the elegant piece of software
that it is and the ease with which powerful applications can rapidly
be produced and we wanted to utilize the framework in other
situations.
Just to poke some fun here... "Django" is apparently named after the
jazz musician. The basic tenet of jazz is that everyone starts by
operating within an agreed upon set of rhythms and keys but at some
point the individuals are free to deviate and express themselves. As
an analogy to the framework, it seems like the expectation is more
that everyone stays on beat and in tune. Maybe you should rename it
to James (as in Brown) since the James Brown band presented the
illusion of being freestyle but were really carefully choreographed
according to subtle movements and signals by Mr. Brown. Ok ok just
kidding :)
I've started looking through the framework code regarding our friend
the connection and I feel like with a few well placed, minimal changes
the flexiblity some of us desire is well possible. Yes I know its up
to us to do the legwork. I guess I was just hoping for more
constructive support from those closely involved with the project.
Let's pretend for a moment that Django did support multi-DB and multi-
user connections. Guess what? You can still specify a single
connection to a single database for the scope of your application!
Rather than hearing the repeated arguments of what represents poor
application design or security risks please try to remember that for
some of us those design decisions or use cases are out of our
control. I am going to hold out hope that some of the people who are
more intimately familiar with the code base will change their minds
and offer up suggestions or tips about strategies ("try modifying this
but watch out for this, etc.") so that those of us who want to shoot
ourselves in the foot can do so - even if those who can provide such
advice would never ever think to use or design an application in that
manner. Speaking for myself and perhaps most of those who have voiced
an interest, I am just trying to add to the types of scenarios where
Django can be used to kick some a**. Its a little bit of a bummer
when the responses seem to challenge people's motivation for wanting
to use a framework they also feel passionate about for use cases that
really do exist.
-Brian
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
