Tim, Thanks for your tip, I was able to maintain the correct value in the current session and retrieve it in the next request as you had suggested.
This solved the issue of two different clients hitting the server as they have unique session_keys. An exception here is if I have two browsers opened on the same client. One browser hitting table_view, second tab also hitting table_view and subsequently hitting csv_view on browser window 1 I get stale data. Is there a trick to avoid this scenario? On Mar 3, 2:57 am, Tim Chase <django.us...@tim.thechases.com> wrote: > GP wrote: > > I have a view which generates a table (table_view) of the most recent > > entries entered in the Test table of the database. I have the option > > of querying the database and render the table based on the user > > criteria as well > > > Something like this: tests = Test.objects.filter(field1 = .......) > > > The search form is passed as a GET request method. > > > I have a second view which uses this dynamic data retrieved from the > > database and provides it as a csv (csv_view). For this to happen I > > save the variable 'tests' as a global variable and then access it in > > my csv_view to generate the csv file. > > 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. > > > I know that using the global variable is not a good idea but was a > > quick fix when I was writing this view. I am not sure how else to pass > > the query from the table_view to the csv_view otherwise. > > 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. > > 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. > > -tim --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
