On 1/9/07, David Cramer <[EMAIL PROTECTED]> wrote: > I'd like to come up with an optional, or simply, a solution for our > framework, where designers do not get access to do the SQL through the > template on related attributes.
Also, bear in mind that this option locks you in to the unpleasant situation of never being able to use certain data or to present them the way you'd like; any method of getting that data at some other part of the request/response cycle would just re-introduce the queries somewhere else and you'd be back to figuring out how to deal with them. Judging from what you've said, your database simply is not capable of handling the level of traffic you're imposing on it, and no amount of shuffling will help, so you seem to be stuck giving up on the data -- trying to do the queries "up front" in the view makes no difference, because template rendering technically happens in the view; at best, you'd just be making the same number of queries, just some of them would happen a fraction of a second sooner. And, of course, the best solution of all is not to hack away on anything until you've figured out exactly what data you want and exactly which queries you need to execute to get it, and explored whether you can optimize or cache any of them you haven't already cached or optimized. Remember that there are a *lot* of options for caching, and they often go a long way. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---
