> This is bound to fail when user A hits view #1, then user B hits > view #1 (overwriting A's global), then user A hits view #2, > seeing B's results.
Yep, figured that out the hard way > your views should be fairly stateless, relying only on > information coming from the user -- whether stored in a session, > or stored in a database/cache and keyed on the request > parameters. Depending on the size of the queryset, you can > either just rerun the query, or you can cache the results (Django > has several nice facilities for caching) and then hand off the > key/token to the page so that it's available in the next GET > request. Or store the key in your current session, and then > retrieve it on the next request. Thanks, I am looking into this http://www.djangoproject.com/documentation/0_91/cache/ > It's also helpful to have a Subject line apropos of the actual > subject matter -- CSV had nothing to do with the actual problem > of global variable use in Django. As such, I've changed it. WIll do .. --~--~---------~--~----~------------~-------~--~----~ 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
