I don't think you understand. We do not want the template to be able to execute any queries that have not already been done by the time it's hit the render phase. If it hasnt been executed, we don't want it accessible. The reason for this is to stop queries going outside of our cache and/or view.
Yes, this may limit templates, but it's a good limitation, there should be no reason a template should have to pull information from the database. Why? Because you can't cache the data within the template, it is hit EVERY SINGLE TIME the page is loaded. So let's say for example, we have a page, that displays 100 search results, and for some reason or another, we didn't have the user field selected in these results, and the template is calling the user field. We now have a template executing 100 select queries EVERY SINGLE VIEW. Do you understand why this needs changed? On Jan 10, 4:22 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
