Re: database connection user - newbie question
The single piece of Django that I'm most hungry for right now is the bit that pushes translated strings up into your javascript. If it's feasible to use just that bit, and keep my own connection paradigm, it could be a short-term solution. Thanks again all for your time and energy on this thread - and Brian for the humour. I am significantly more informed about Django and some of my own choices than I was last week. Foob On May 12, 3:41 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > 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 -~--~~~~--~~--~--~---
Re: database connection user - newbie question
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 -~--~~~~--~~--~--~---
Re: database connection user - newbie question
I think we have reached the dead horse phase of this discussion. Since it has become so lengthy and confusing for some (at least for me it has), I wanted to summarize what was accomplished. Thank you all for your responses. I feel like I have a much better sense of Django's current intended target use and I feel confident that I understand and concur with the philosophy behind Django's database paradigm. Hopefully there were some positive points taken away from the debate. Disclaimer: The following summary is intended to be tongue-in-cheek and is not meant to imply the opinions of anyone specifically. user: Hi I'd like to be able to connect to multiple databases and/or specify connections dynamically for my Django app. response: Why would you want to do something like that? It's bad design and it doesn't represent any real world scenarios. user: I actually do have a real world scenario and I understand the potential security and performance implications. I want to plow ahead anyway and I promise not hold the Django team responsible for any self- inflicted damage. Any suggestions for implemenation strategy? response: This is not a feature that is a high-level priority for the development team right now. You are welcome to volunteer your own time to try to tackle something like this. user: Great! I'm ready to start working and was thinking that maybe there were some helpful suggestions of where to look or what to watch out for. response: Why do you think the developers don't want this feature? We are incredibly eager to see progress made on this front. If you want it in there go ahead and take the lead. user: Yep, I'm all set to get started! Anyone have any helpful hints or guidelines? response: Well first of all, why would you want to do something like this? Separating logical databases and allowing users to specify the database account is just not something people should be doing with modern technology stacks. user: I completely 1000% agree that there are implications with these types of usage patterns. I was hoping to use Django in a few situations where there is in fact a need for this type of functionality. While I'd love to both redesign the legacy databases and convince the DBA that mixing framework meta tables into his warehouse is a workable scenario, it is not feasible for our business or timelines at the moment. I love the cohesive feel and power of Django and having invested time learning the framework I was simply hoping to be able to spend my own time making some tweaks that would allow for this type of use. I was thinking that maybe some of the more knowledgeable people in the community would have some helpful pointers about how they would proceed if they were going to implement something like that. response: We are very eager to have something like that and in fact there is a branch out there that you are welcome to submit patches for. We just have too many people who abandon these branches and it doesn't make sense for us to spend cycles on maintaining that right now. It seems like you are not understanding the commitment to getting this feature implemented that we have and you should feel free to take on the work yourself if you are passionate about it. user: Ok understood. I'd like to take a stab at it. Does anyone know offhand if there would be problems overriding the connection on a per request basis? Any gotchas? It could be that the ORM would need a significant overhaul to support something like this. Any ideas? I was just thinking that before I volunteer my time and potentially go down the wrong road, someone might have some insights to share. response: What you're attempting is not something Django was designed for. Allowing an application to specify connections based on application credentials is a dangerous practice. Overall you are missing the point here. We want this functionality and we encourage people to take the lead on functionality they'd like to see but no one is stepping up to do this and this discussion is more or less pointless. user: who's on first again? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: database connection user - newbie question
Hey Waylan, "What you seem to be missing is that the core devs are not questioning that." Ok, I think what's happening here is that one or more of us needs to improve our communication skills - present company potentially included. If you got that impression than I did not make my thoughts clear enough. I felt like I acknowledged that I understand that the devs do see value in a more flexible scheme. I've even been told directly by a few people that yes, they'd be happy to see that feature and that it is just not a priority for their current road map. Got it. Understood. Check :) "Rather, they are all in situations were they don't need multi-db support." I feel like I have acknowledged that I understand this. I understand that Django is a volunteer project. I feel blessed that we have something that is maturing nicely so us Pythoneers can play in the web dev world on the same field as other languages. I think it is fantastic. I was involved with the PRADO project over in PHP land for a while and I can sympathize with the feeling of being pressured to integrate everything under the sun as well as the disappointment that comes with not being able to please everyone. "But that it *not* what they said. In fact, when the multi-db branch started (over a year ago) they seemed eager to see something they could include into trunk. Unfortunelty, that something has not materialized as noone (that needs that feauture and can therefore adequeatly test it etc.) has stepped up to the plate to finish development and comitt to long term maintanence." This is the part that is "troubling" to me. This "eagerness" that you describe is at the very root of what I'm trying to get to the bottom of. If you read through the history of this thread and recent others, there are some lengthy and well composed responses to people who have inquired about the best way to realize this type of functionality. I would have expected more in the way of specific code suggestions - i.e "we understand some people want this... not on our radar... we'd like to see it too but have some reservations about security and performance implications...we still have some decisions to make as a team regarding how this functionality complements our goals for the framework...if you'd like to take a stab, take a look at module X and files A,B and C...watch out for this...thing X is tightly coupled to class Y at the moment and you'll have to find a way around that...". I don't know how to be any more explicit in what I'm looking for. I AM NOT asking the developers to do any work on this. I AM NOT expecting the developers to create, assist in, or maintain a branch for myself or anyone else. I AM NOT expecting the developers to embrace, endorse, or condone the use of Django in multilple database and/or dynamic connection scenarios. I AM willing to put in some work and assist others who share my desire to have this type of functionality available. Honestly, for all time put forth for some people's responses, I clearly must have missed these implementation- specific suggestions. I will go back and carefully re-read this discussion so I can ferret out these pearls of wisdom. Either that or I was flat out wrong to assume that some of the people who are intimately familiar with the internal workings of Django would be willing to provide at the least very high-level constructive advice regarding an implementation strategy for these types of features. I hope to be an active participant in this community and I apologize for turning this into a pointless discussion and wasting people's time. -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 -~--~~~~--~~--~--~---
Re: database connection user - newbie question
> well. Sure, someone mentioned the possability of some money for > development, but that doesn't cover the long term maintianence, which is > what the core devs are looking for. If someone is offering to pay for development of a feature that will enable them to use the framework for their software, do you really think they're going to neglect the maintenance of this feature in the long run? On May 11, 11:47 am, Waylan Limberg <[EMAIL PROTECTED]> wrote: > On Thu, 2007-05-10 at 22:58 +, [EMAIL PROTECTED] wrote: > > > 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. > > What you seem to be missing is that the core devs are not questioning > that. Rather, they are all in situations were they don't need multi-db > support. Some here seem to have taken their explaination to mean they > don't want mutli-db support. But that it *not* what they said. In fact, > when the multi-db branch started (over a year ago) they seemed eager to > see something they could include into trunk. Unfortunelty, that > something has not materialized as noone (that needs that feauture and > can therefore adequeatly test it etc.) has stepped up to the plate to > finish development and comitt to long term maintanence. Remember, the > core devs are all doing this in their free time not-for-pay. Therefore, > they are are scratching their own itch. Your welcome to scratch yours as > well. Sure, someone mentioned the possability of some money for > development, but that doesn't cover the long term maintianence, which is > what the core devs are looking for. > > This same debate has been played over and over for all of the stagnet > branches and, quite frankly, I'm getting tired of the pointlesness of it > all. No wonder Adrian and Jacob never (rarely?) respond to these kinds > of messages anymore. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: database connection user - newbie question
On Thu, 2007-05-10 at 22:58 +, [EMAIL PROTECTED] wrote: > > 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. What you seem to be missing is that the core devs are not questioning that. Rather, they are all in situations were they don't need multi-db support. Some here seem to have taken their explaination to mean they don't want mutli-db support. But that it *not* what they said. In fact, when the multi-db branch started (over a year ago) they seemed eager to see something they could include into trunk. Unfortunelty, that something has not materialized as noone (that needs that feauture and can therefore adequeatly test it etc.) has stepped up to the plate to finish development and comitt to long term maintanence. Remember, the core devs are all doing this in their free time not-for-pay. Therefore, they are are scratching their own itch. Your welcome to scratch yours as well. Sure, someone mentioned the possability of some money for development, but that doesn't cover the long term maintianence, which is what the core devs are looking for. This same debate has been played over and over for all of the stagnet branches and, quite frankly, I'm getting tired of the pointlesness of it all. No wonder Adrian and Jacob never (rarely?) respond to these kinds of messages anymore. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: database connection user - newbie question
"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
Re: database connection user - newbie question
Re: "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." At the company I'm currently working for, we have a 'sister' company, which we receive some data. For legal purposes, they must 'own' that data, and it must reside on separate database servers. The web app I'm creating for the my company (which will also be used as a tool by our 'sister' company), has the need to view/update data from both databases. Just wanted to give a real-world scenario in response to the question On May 10, 1:35 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 5/9/07, foobarmus <[EMAIL PROTECTED]> wrote: > > > 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. > > 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. > > Rambling historical anecdote: > > Many large organizations have IT policies which require users to > change their passwords every so often, usually once every 30 or 90 > days. This is touted as a security requirement for sensitive data, and > it's rare that anyone asks what actual security problem the password > changes solve. As it turns out, the origin of this recommendation was > an analysis of how long it would take to brute-force a password on a > 1970s-era mainframe -- the recommended period for changing passwords > was set to be shorter than the time it would take to try every > possible password. > > Modern systems are far faster, and brute-forcing a password can now be > a matter of hours or even minutes. Newer, stronger methods -- such as > better physical and network security controlling access to the system, > and "locking out" a user after a relatively low number of failed login > attempts -- now mitigate this risk far more effectively than any > "change your password every X days" policy. Additionally, such a > policy actually increases the risk of a breach -- frequent password > changes encourage users to choose weaker passwords, or to write down > their passwords and leave the information in easily-accessible places. > > But most companies still have a mandatory password-change policy, > because the organizational inertia of "we've always done it that way, > and everybody else does it that way" discourages questioning. > > Similarly, I have a feeling that segregation of databases and the sort > of access controls you're proposing have their roots in much older > systems where users had more or less direct access to the database > server and this was the most effective way to manage the users. > > But modern applications almost invariably introduce a mediating layer > between the user and the database, effectively moving access controls > to another layer of the stack. For example, in a web application a > user can only access data through the interface exposed by the > application; there's no way to "drop down" and avoid that layer. This > means that the application can control access and hide implementation > details in much the same way as database-level views and stored > procedures. > > This is why so many web applications use only a single logical > database, and access it through a single database-level user; the > application logic should already be taking some access controls into > account (for example, if the user isn't allowed to view records from a > particular table, the application should never even display an option > to do so) anyway, so moving more access-control logic to the > application layer becomes a more attractive option. > > Moving access-control logic "up the stack" into the application layer > also increases the flexibility you have when designing and optimizing > the database (since you're not bound to a particular design from the > start), and allows easier modification of the application; with > pass-through authentication and DB-level segregated access, any change > to the authentication scheme must occur in two places: first, the > change must be made in the database layer, then corresponding changes > must be made in the application layer. By contrast, keeping as much > access-control logic as possible at the application layer means that > you have a single place where changes can be made (and remember that > application-level changes are often easier to manage than > database-level changes); this is the DRY principle at work. > > Given that,
Re: database connection user - newbie question
> Furthermore, in the general case, business logic is too complex to be > implemented simply in the database layer - significant business logic > would need stored procedures, triggers etc. which are inherently non- > portable across RDBMS platforms. Portability across RDBMS platforms is a pipe dream for anything except "happy apps". Forgive me for creating a serious database. If no-one here wants to talk to me about Django functionality, I'm not going to hang around. See you all, and thanks for the time you've taken to write your responses. On May 10, 5:25 pm, Vinay Sajip <[EMAIL PROTECTED]> wrote: > On May 10, 7:37 am, foobarmus <[EMAIL PROTECTED]> wrote: > > > 1. RDBMSs like PostgreSQL, Oracle, perhaps even MySQL although it's > > still a fledgling in this regard (to name but 3), were designed to (or > > have subsequently been revamped to) handle the kind of business logic > > that large organisations demand. Web frameworks like Django invariably > > are not designed to handle such business logic. This is not a > > I'm probably misunderstanding something, but surely business logic is > the province of your application, and not of Django itself. > Furthermore, in the general case, business logic is too complex to be > implemented simply in the database layer - significant business logic > would need stored procedures, triggers etc. which are inherently non- > portable across RDBMS platforms. Also, in some scenarios, business > logic encompasses things which are not easily embeddable in the > database layer (e.g. sending out notification emails in a workflow > process). While Django is more focused on a model-driven approach from > which it works out and executes the SQL you need, there's no reason > you can't just use the urls and views part of Django and use e.g. DB- > API directly and provide complex business logic via code called from > your views. If you are using Django models, the model managers seem to > be the right place to put this kind of logic. > > Although Django does not yet provide all the hooks that are desirable > for some business needs - (e.g. support for views and stored > procedures and schema migration, a more generic authorization scheme) > it looks as if there is work in various branches towards providing > more functionality in at least some of these areas. > > My 2¢, > > 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 -~--~~~~--~~--~--~---
Re: database connection user - newbie question
On May 10, 7:37 am, foobarmus <[EMAIL PROTECTED]> wrote: > 1. RDBMSs like PostgreSQL, Oracle, perhaps even MySQL although it's > still a fledgling in this regard (to name but 3), were designed to (or > have subsequently been revamped to) handle the kind of business logic > that large organisations demand. Web frameworks like Django invariably > are not designed to handle such business logic. This is not a I'm probably misunderstanding something, but surely business logic is the province of your application, and not of Django itself. Furthermore, in the general case, business logic is too complex to be implemented simply in the database layer - significant business logic would need stored procedures, triggers etc. which are inherently non- portable across RDBMS platforms. Also, in some scenarios, business logic encompasses things which are not easily embeddable in the database layer (e.g. sending out notification emails in a workflow process). While Django is more focused on a model-driven approach from which it works out and executes the SQL you need, there's no reason you can't just use the urls and views part of Django and use e.g. DB- API directly and provide complex business logic via code called from your views. If you are using Django models, the model managers seem to be the right place to put this kind of logic. Although Django does not yet provide all the hooks that are desirable for some business needs - (e.g. support for views and stored procedures and schema migration, a more generic authorization scheme) it looks as if there is work in various branches towards providing more functionality in at least some of these areas. My 2¢, 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 -~--~~~~--~~--~--~---
Re: database connection user - newbie question
> Ultimately, this is a tradeoff. What happens when another app wants to > use data from the same database but has less strict auth/access > requirements? So long as you know that only one application with only > one relatively-unchanging set of requirements will ever access the > database, you'll be OK, but the moment you have multiple apps, > multiple auth/access requirements or changes to the auth/access > requirements, the inflexible nature of hard-coding access at the DB > level will start causing you pain. Access requirements, in this context, represent a relationship between the business and the data. As such, they have nothing to do with any application that's putting its own arbitrary logic in-between. > By the same argument, the organization's DBA is also outside your > control and could just as easily wreak havoc. As the old saying goes: > when you invent an idiot-proof system, the world will compensate by > producing more advanced idiots. Funny, but getting back to the argument, DBAs are not idiots. The DBA's job in the organisation is to make the database run smoothly. On May 10, 3:23 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 5/10/07, foobarmus <[EMAIL PROTECTED]> wrote: > > > Unfortunately, pushing access control up the stack means I > > have to rewrite all the functionality has been carefully and > > comprehensively facilitated by my RDBMS. Also it means that access > > control logic has to be written into every app that connects to the > > database - instead of just having it in the database itself. > > Ultimately, this is a tradeoff. What happens when another app wants to > use data from the same database but has less strict auth/access > requirements? So long as you know that only one application with only > one relatively-unchanging set of requirements will ever access the > database, you'll be OK, but the moment you have multiple apps, > multiple auth/access requirements or changes to the auth/access > requirements, the inflexible nature of hard-coding access at the DB > level will start causing you pain. > > > 2. When my app gets installed in an organisation, developers outside > > my control will be modifying and maintaining that instance. It would > > be easy for them to write an incorrect script that gave too much power > > to a user, and nothing would stop it from corrupting the database > > because of course with these "modern applications" the database > > connection is always made by a super-like-user that can do anything > > inside the application's database. > > By the same argument, the organization's DBA is also outside your > control and could just as easily wreak havoc. As the old saying goes: > when you invent an idiot-proof system, the world will compensate by > producing more advanced idiots. > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: database connection user - newbie question
On 5/10/07, foobarmus <[EMAIL PROTECTED]> wrote: > Unfortunately, pushing access control up the stack means I > have to rewrite all the functionality has been carefully and > comprehensively facilitated by my RDBMS. Also it means that access > control logic has to be written into every app that connects to the > database - instead of just having it in the database itself. Ultimately, this is a tradeoff. What happens when another app wants to use data from the same database but has less strict auth/access requirements? So long as you know that only one application with only one relatively-unchanging set of requirements will ever access the database, you'll be OK, but the moment you have multiple apps, multiple auth/access requirements or changes to the auth/access requirements, the inflexible nature of hard-coding access at the DB level will start causing you pain. > 2. When my app gets installed in an organisation, developers outside > my control will be modifying and maintaining that instance. It would > be easy for them to write an incorrect script that gave too much power > to a user, and nothing would stop it from corrupting the database > because of course with these "modern applications" the database > connection is always made by a super-like-user that can do anything > inside the application's database. By the same argument, the organization's DBA is also outside your control and could just as easily wreak havoc. As the old saying goes: when you invent an idiot-proof system, the world will compensate by producing more advanced idiots. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: database connection user - newbie question
On 5/9/07, foobarmus <[EMAIL PROTECTED]> wrote: > 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. 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. Rambling historical anecdote: Many large organizations have IT policies which require users to change their passwords every so often, usually once every 30 or 90 days. This is touted as a security requirement for sensitive data, and it's rare that anyone asks what actual security problem the password changes solve. As it turns out, the origin of this recommendation was an analysis of how long it would take to brute-force a password on a 1970s-era mainframe -- the recommended period for changing passwords was set to be shorter than the time it would take to try every possible password. Modern systems are far faster, and brute-forcing a password can now be a matter of hours or even minutes. Newer, stronger methods -- such as better physical and network security controlling access to the system, and "locking out" a user after a relatively low number of failed login attempts -- now mitigate this risk far more effectively than any "change your password every X days" policy. Additionally, such a policy actually increases the risk of a breach -- frequent password changes encourage users to choose weaker passwords, or to write down their passwords and leave the information in easily-accessible places. But most companies still have a mandatory password-change policy, because the organizational inertia of "we've always done it that way, and everybody else does it that way" discourages questioning. Similarly, I have a feeling that segregation of databases and the sort of access controls you're proposing have their roots in much older systems where users had more or less direct access to the database server and this was the most effective way to manage the users. But modern applications almost invariably introduce a mediating layer between the user and the database, effectively moving access controls to another layer of the stack. For example, in a web application a user can only access data through the interface exposed by the application; there's no way to "drop down" and avoid that layer. This means that the application can control access and hide implementation details in much the same way as database-level views and stored procedures. This is why so many web applications use only a single logical database, and access it through a single database-level user; the application logic should already be taking some access controls into account (for example, if the user isn't allowed to view records from a particular table, the application should never even display an option to do so) anyway, so moving more access-control logic to the application layer becomes a more attractive option. Moving access-control logic "up the stack" into the application layer also increases the flexibility you have when designing and optimizing the database (since you're not bound to a particular design from the start), and allows easier modification of the application; with pass-through authentication and DB-level segregated access, any change to the authentication scheme must occur in two places: first, the change must be made in the database layer, then corresponding changes must be made in the application layer. By contrast, keeping as much access-control logic as possible at the application layer means that you have a single place where changes can be made (and remember that application-level changes are often easier to manage than database-level changes); this is the DRY principle at work. Given that, it's worth asking whether the solutions you're proposing are still the most effective, or whether they've reached the organizational-inertia stage of "we've always done it this way". Relying heavily on database-level access controls and segregated databases may be a good fit for a particular application, of course, but the best thing to do is determine that up-front before making an architectural decision; committing to it will significantly increase the complexity -- and, by extension, the cost both for development and maintenance -- of the application, and if you can avoid that complexity you should. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this
Re: database connection user - newbie question
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. For more information about the philosophy behind Django's database connection operation " 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,
Re: database connection user - newbie question
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
Re: database connection user - newbie question
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 -~--~~~~--~~--~--~---
Re: database connection user - newbie question
foobarmus wrote: > 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. I think it's important. I > don't understand why frameworks like Django don't allow for it. It is > not difficult to do. > The main reasons I can see on why people ignored using db-user based ACL's are: - They only offer functionality controlling access at the table/row level. most ACLs are based on function and possibly column-level access. eg. user joe can only authorize/access accounts in his sales region, and on orders less than $5k can't be done in a DB-based ACL. - Most larger organizations favor single sign on for their authentication, which means control goes out of the database,. - Not everything is in a database, and some things span multiple databases. - Basic security can be achieved with 2 users. a public facing very limited user with mainly read only access. and a high auth user on a seperate port/webserver instance with higher level access. - It requires interaction with a DBA. This is a expensive and scarce resource in most organizations. So people routed around them. (I've been in several orgs where projects are held up on DBAs who are needed to write sprocs instead of just doing simple SQL). - A large proportion of apps don't need ACLs. Those are some of the reasons which come off the top of my head, I'm sure there are more > Is there some popular wisdom on this issue that I haven't been exposed > to? > > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: database connection user - newbie question
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
Re: database connection user - newbie question
On 5/9/07, foobarmus <[EMAIL PROTECTED]> wrote: > > 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. I think it's important. I > don't understand why frameworks like Django don't allow for it. It is > not difficult to do. > > Is there some popular wisdom on this issue that I haven't been exposed > to? 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. If you are willing to _meticulously_ audit every security implication then good luck. 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). 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... Regards, -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
