gaeutilities - Project Hosting on Google Code

Earlier this year Oct 05, 2009 issue 41 (Session mysteriously stops) Status changed by bowman.joseph - This ticket has been moved to github, please follow up there Status: Done This ticket has been moved to github, please follow up there Status: Done Oct 05, 2009 issue 40 (Add a .model() method to Session, to return the model entity...) Status changed by bowman.joseph - moved - http://github.com/joerussbowman/gaeutilities/issues/#issue/3 Status: WontFix moved - http://github.com/joerussbowman/gaeutilities/issues/#issue/3 Status: WontFix Oct 05, 2009 issue 38 (Session could be overhauled again for performance) Status changed by bowman.joseph - Status: WontFix Status: WontFix Oct 05, 2009 issue 38 (Session could be overhauled again for performance) commented on by bowman.joseph - Moved - http://github.com/joerussbowman/gaeutilities/issues/#issue/2 Moved - http://github.com/joerussbowman/gaeutilities/issues/#issue/2 Oct 05, 2009 issue 37 (Need to handle object serialization better) Status changed by bowman.joseph - Status: WontFix Status: WontFix Oct 05, 2009 issue 15 (Admin interface for utilities) Status changed by bowman.joseph - Moved - http://github.com/joerussbowman/gaeutilities/issues#issue/1 Status: Fixed Moved - http://github.com/joerussbowman/gaeutilities/issues#issue/1 Status: Fixed Oct 05, 2009 issue 2 (Typo in Event demo page) Status changed by bowman.joseph - Status: Fixed Status: Fixed Oct 05, 2009 issue 41 (Session mysteriously stops) commented on by bowman.joseph - I was using openid/oauth/facebook connect for my application, and had the same issue with the development server, but found it was not a problem on the live servers. I never took the time to track down the issue with the dev server, as I just found in general it had some oddities involved with restart, so I would just log back in. I was using openid/oauth/facebook connect for my application, and had the same issue with the development server, but found it was not a problem on the live servers. I never took the time to track down the issue with the dev server, as I just found in general it had some oddities involved with restart, so I would just log back in. Oct 04, 2009 issue 41 (Session mysteriously stops) commented on by brianmh...@gmail.com - It seems I jumped the gun. I can't explain why the sessions mysteriously disappear. I'll keep probing with the suggestions you've helpfully given, Joseph, and follow up on here once I determine something conclusive. Thank you. It seems I jumped the gun. I can't explain why the sessions mysteriously disappear. I'll keep probing with the suggestions you've helpfully given, Joseph, and follow up on here once I determine something conclusive. Thank you. Oct 04, 2009 issue 41 (Session mysteriously stops) commented on by brianmh...@gmail.com - Thank you for the response and suggesting places to look. It looks like the session is lost whenever I make changes to my application, which is running on the development server (GAE 1.2.5). Since my session is keeping the login credentials (i.e. OpenID), it looks like I may have to create a session driver (i.e. a faux session) while I'm developing, or log in every time I make a change. Although those workarounds will work, I'd also be much obliged if you happened to have any suggestions for keeping sessions across restarts (during the development process). Thank you for the response and suggesting places to look. It looks like the session is lost whenever I make changes to my application, which is running on the development server (GAE 1.2.5). Since my session is keeping the login credentials (i.e. OpenID), it looks like I may have to create a session driver (i.e. a faux session) while I'm developing, or log in every time I make a change. Although those workarounds will work, I'd also be much obliged if you happened to have any suggestions for keeping sessions across restarts (during the development process). Oct 03, 2009 issue 41 (Session mysteriously stops) commented on by bowman.joseph - Session, by default, relies on the cookie, ip address, and user agent of the browser to persist. I have seen cases where the local development server, on restart, will lose the session. Is this what is going on, or are you experiencing this on the live server? You can try turning off user agent checking and ip checking in the settings file to see if that helps. You can also turn the clean check percent to 0, and track your cookies in your browser on each request to see if you can figure out where it's being dropped. The reason you're only seeing one session is it's highly likely any expired session is getting deleted. Lastly, do you have a lot of AJAX requests going on your page? The 3 token system should be fine with this, but just a thought. Session, by default, relies on the cookie, ip address, and user agent of the browser to persist. I have seen cases where the local development server, on restart, will lose the session. Is this what is going on, or are you experiencing this on the live server? You can try turning off user agent checking and ip checking in the settings file to see if that helps. You can also turn the clean check percent to 0, and track your cookies in your browser on each request to see if you can figure out where it's being dropped. The reason you're only seeing one session is it's highly likely any expired session is getting deleted. Lastly, do you have a lot of AJAX requests going on your page? The 3 token system should be fine with this, but just a thought. Oct 02, 2009 issue 41 (Session mysteriously stops) reported by brianmh...@gmail.com - What steps will reproduce the problem? This is oversimplified, but essentially: 1. In Django Create a session likeso: from appengine_utilities import sessions Here is a Django view def signin(request): request.session = sessions.Session() request.session['person'] = 'identity' There are other views that access request.session['person'], e.g.: def do_something(request): return HttpResponse("Person: %s" % request.session['person']) 2. View a page or two within the next 30 seconds to 2 minutes, and request.session data will be {'person':'identity'}. Sometimes the request.session data lasts for an hour. Other times it disappears after seconds. 3. Mysteriously request.session becomes {} What is the expected output? What do you see instead? I would expect that request.session would not lose its information. What version of the product are you using? On what operating system? - Gae Utilities 1.3 - GAE Dev. 1.2.5 SDK - Django 1.0 (from get_version()) Please provide any additional information below. I note that after the session has disappeared _AppEngineUtilities_Session in GAE datastore contains a sid equal to the value of a gaeutilities_session cookie. There is nothing else in the datastore (i.e. no _AppEngineUtilities_SessionData) I'm afraid I'm just not using gaeutilities sessions properly, but I've tried everything I can think of so I think there is still something amiss, here. Is there any more information I could provide that may be of assistance? Thank you. What steps will reproduce the problem? This is oversimplified, but essentially: 1. In Django Create a session likeso: from appengine_utilities import sessions Here is a Django view def signin(request): request.session = sessions.Session() request.session['person'] = 'identity' There are other views that access request.session['person'], e.g.: def do_something(request): return HttpResponse("Person: %s" % request.session['person']) 2. View a page or two within the next 30 seconds to 2 minutes, and request.session data will be {'person':'identity'}. Sometimes the request.session data lasts for an hour. Other times it disappears after seconds. 3. Mysteriously request.session becomes {} What is the expected output? What do you see instead? I would expect that request.session would not lose its information. What version of the product are you using? On what operating system? - Gae Utilities 1.3 - GAE Dev. 1.2.5 SDK - Django 1.0 (from get_version()) Please provide any additional information below. I note that after the session has disappeared _AppEngineUtilities_Session in GAE datastore contains a sid equal to the value of a gaeutilities_session cookie. There is nothing else in the datastore (i.e. no _AppEngineUtilities_SessionData) I'm afraid I'm just not using gaeutilities sessions properly, but I've tried everything I can think of so I think there is still something amiss, here. Is there any more information I could provide that may be of assistance? Thank you. Sep 28, 2009 issue 38 (Session could be overhauled again for performance) changed by bowman.joseph - Status: Accepted Owner: bowman.joseph Status: Accepted Owner: bowman.joseph Sep 28, 2009 issue 40 (Add a .model() method to Session, to return the model entity...) reported by bowman.joseph - This will make it easier to use a ReferenceProperty for tieing sessions to accounts. This will make it easier to use a ReferenceProperty for tieing sessions to accounts. Sep 27, 2009 gaeutilities-1.3.tgz (gaeutilties-1.3.tgz) file uploaded by bowman.joseph - Labels: Featured Type-Source Labels: Featured Type-Source Sep 27, 2009 r133 (1.3 release) committed by bowman.joseph - 1.3 release 1.3 release Sep 27, 2009 r132 (forgot to update changelog ) committed by bowman.joseph - forgot to update changelog forgot to update changelog Sep 27, 2009 r131 (createing 1.3 release ) committed by bowman.joseph - createing 1.3 release createing 1.3 release Sep 27, 2009 r130 (updated demo) committed by bowman.joseph - updated demo updated demo Sep 27, 2009 issue 39 (Undefined variables) changed by bowman.joseph - This should be fixed in trunk now. Status: Fixed Owner: bowman.joseph This should be fixed in trunk now. Status: Fixed Owner: bowman.joseph Sep 27, 2009 r129 (Fixed a couple typos in sessions.py) committed by bowman.joseph - Fixed a couple typos in sessions.py Fixed a couple typos in sessions.py Sep 26, 2009 issue 39 (Undefined variables) reported by brianmh...@gmail.com - Pyflakes notes the following: sessions.py:249: undefined name 'session_key' sessions.py:840: undefined name 's' I expect 249 should be self.session_key. Line 840 should read ["%s_data" % (self.cookie_name)] Cheers. Pyflakes notes the following: sessions.py:249: undefined name 'session_key' sessions.py:840: undefined name 's' I expect 249 should be self.session_key. Line 840 should read ["%s_data" % (self.cookie_name)] Cheers. Sep 25, 2009 Cache Wiki page commented on by bowman.joseph - thanks, got it thanks, got it Sep 25, 2009 Cache Wiki page edited by bowman.joseph - Revision r128 Edited wiki page through web user interface. Revision r128 Edited wiki page through web user interface. Sep 25, 2009 Cache Wiki page commented on by hervandevliert - In the example is a small typo 'from appengine_utilities.sessions import Cache' must be changed to 'from appengine_utilities.cache import Cache'. In the example is a small typo 'from appengine_utilities.sessions import Cache' must be changed to 'from appengine_utilities.cache import Cache'. Sep 23, 2009 r127 ( removing paginator, never worked, there are better solution...) committed by bowman.joseph - removing paginator, never worked, there are better solutions available in the cookbook removing paginator, never worked, there are better solutions available in the cookbook Sep 22, 2009 issue 38 (Session could be overhauled again for performance) reported by bowman.joseph - There's a lot of serialization that happens with session. Except for Models, anything going in as a session data item is pickled on write. So reads are unpickled, which in appengine can be a little heavy. A few ideas are - Catch any items that can be stored as string/unicode, and store them as that in a TextProperty, rather than the BlobProperty. I believe in most cases, this plus the change mentioned above for Models should cover most uses of session. This means pickle, in most applications, may not be used at all. - To completely optmize, session can include a WSGI Middleware which would handle all the serialization at the end of the request. Using the internal per request cache (cache attribute on the Session object) to handle the data until the request is over and everything is written to the datastore. May even be able to speed up the overall write speed of the datastore by doing one db.put for all items. Note: I'm not accepting this at this time, though this is fair game for anyone to take on AFTER the 1.3 release. There's a lot of serialization that happens with session. Except for Models, anything going in as a session data item is pickled on write. So reads are unpickled, which in appengine can be a little heavy. A few ideas are - Catch any items that can be stored as string/unicode, and store them as that in a TextProperty, rather than the BlobProperty. I believe in most cases, this plus the change mentioned above for Models should cover most uses of session. This means pickle, in most applications, may not be used at all. - To completely optmize, session can include a WSGI Middleware which would handle all the serialization at the end of the request. Using the internal per request cache (cache attribute on the Session object) to handle the data until the request is over and everything is written to the datastore. May even be able to speed up the overall write speed of the datastore by doing one db.put for all items. Note: I'm not accepting this at this time, though this is fair game for anyone to take on AFTER the 1.3 release. Sep 22, 2009 issue 37 (Need to handle object serialization better) commented on by bowman.joseph - I ended up detecting models, and making them reference properties rather than serialized anything. This should be even quicker and cleaner for load times. I ended up detecting models, and making them reference properties rather than serialized anything. This should be even quicker and cleaner for load times. Sep 22, 2009 r126 (believe I have it working.. still working on unit test pages...) committed by bowman.joseph - believe I have it working.. still working on unit test pages, so once I get sessions done this should look a lot better believe I have it working.. still working on unit test pages, so once I get sessions done this should look a lot better Sep 22, 2009 r125 (almost working, except the model added can't change. I've ma...) committed by bowman.joseph - almost working, except the model added can't change. I've made it a ReferenceProperty, but still not quite working. Commit so as not to lose work, session is unstable at best right now almost working, except the model added can't change. I've made it a ReferenceProperty, but still not quite working. Commit so as not to lose work, session is unstable at best right now Sep 22, 2009 r124 (updating the working version of sessions.py, in order to ask...) committed by bowman.joseph - updating the working version of sessions.py, in order to ask for some help in the appengine-python google group updating the working version of sessions.py, in order to ask for some help in the appengine-python google group Sep 22, 2009 issue 33 (Session needs to retry on read timeouts) Status changed by bowman.joseph - puts are caught by the memcache wrapper, this is available in 1.3rc1, closing the ticket Status: Fixed puts are caught by the memcache wrapper, this is available in 1.3rc1, closing the ticket Status: Fixed Sep 22, 2009 issue 34 (Should improve string handling) Status changed by bowman.joseph - I believe I have this fixed everywhere appropriate Status: Fixed I believe I have this fixed everywhere appropriate Status: Fixed Sep 22, 2009 issue 37 (Need to handle object serialization better) reported by bowman.joseph - Best example of why can be found at this link - http://stackoverflow.com/questions/1449257/google-app-engine-and-python-and-objects-that-pass-by-value/1461932#1461932 I contacted Nick Johnson directly and he suggested : "My suggestion would be one of several: - Hook something that allows you to serialize the session only at the end of the request - for example, WSGI middleware. - Require users to manually call .save() or similar - this would break the interface, of course, so would require it to be an optional mode of operation. - Serialize immediately, but keep the original objects around, which would alleviate the problems the SO user saw." I think I'll look at a combination of option 1 and 2, though need to think about this more. In fact option might be most ideal upon further review. I will have something for this in 1.3 final. Best example of why can be found at this link - http://stackoverflow.com/questions/1449257/google-app-engine-and-python-and-objects-that-pass-by-value/1461932#1461932 I contacted Nick Johnson directly and he suggested : "My suggestion would be one of several: - Hook something that allows you to serialize the session only at the end of the request - for example, WSGI middleware. - Require users to manually call .save() or similar - this would break the interface, of course, so would require it to be an optional mode of operation. - Serialize immediately, but keep the original objects around, which would alleviate the problems the SO user saw." I think I'll look at a combination of option 1 and 2, though need to think about this more. In fact option might be most ideal upon further review. I will have something for this in 1.3 final. Sep 20, 2009 gaeutilities-1.3rc1.tgz (gaeutilties-1.3rc1.tgz) file uploaded by bowman.joseph - Labels: Featured Type-Source Labels: Featured Type-Source Sep 20, 2009 r123 (1.3rc1 release) committed by bowman.joseph - 1.3rc1 release 1.3rc1 release Sep 20, 2009 r122 (forgot to commit changelog ) committed by bowman.joseph - forgot to commit changelog forgot to commit changelog Sep 20, 2009 r121 (updated changelog) committed by bowman.joseph - updated changelog updated changelog Sep 20, 2009 gaeutilities-1.3rc1.tgz (gaeutilties-1.3rc1.tgz) file uploaded by bowman.joseph - Labels: Featured Type-Source Labels: Featured Type-Source Sep 20, 2009 r120 (1.3rc1 release) committed by bowman.joseph - 1.3rc1 release 1.3rc1 release Sep 20, 2009 r119 (forgot to update changelog ) committed by bowman.joseph - forgot to update changelog forgot to update changelog Sep 20, 2009 r118 (Creating 1.3rc1 release ) committed by bowman.joseph - Creating 1.3rc1 release Creating 1.3rc1 release Sep 20, 2009 r117 (couple doc updates for paginator, a test for it is part of t...) committed by bowman.joseph - couple doc updates for paginator, a test for it is part of the demo site redesign that will be in progress now that code updates are in. couple doc updates for paginator, a test for it is part of the demo site redesign that will be in progress now that code updates are in. Sep 20, 2009 r116 (docstring update for rotmodel) committed by bowman.joseph - docstring update for rotmodel docstring update for rotmodel Sep 20, 2009 r115 (couple tweaks for session and flash) committed by bowman.joseph - couple tweaks for session and flash couple tweaks for session and flash Sep 20, 2009 r114 (Added a preSessionDelete event to session) committed by bowman.joseph - Added a preSessionDelete event to session Added a preSessionDelete event to session Sep 20, 2009 r113 (Event docstring cleanup) committed by bowman.joseph - Event docstring cleanup Event docstring cleanup Sep 20, 2009 r112 (Typo fix from the previous commit.) committed by bowman.joseph - Typo fix from the previous commit. Typo fix from the previous commit. Sep 20, 2009 r111 (Optitmization tweaks for string building within the class, m...) committed by bowman.joseph - Optitmization tweaks for string building within the class, mostly for memcache entries. Optitmization tweaks for string building within the class, mostly for memcache entries. Sep 20, 2009 r110 (Updates to cache docstring, and some various tweaks and bugf...) committed by bowman.joseph - Updates to cache docstring, and some various tweaks and bugfixes found during code review, such as missed event firings. Updates to cache docstring, and some various tweaks and bugfixes found during code review, such as missed event firings.

issue 41 (Session mysteriously stops) reported by brianmh...@gmail.com - What steps will reproduce the problem? This is oversimplified, but essentially: 1. In Django Create a session likeso: from appengine_utilities import sessions Here is a Django view def signin(request): request.session = sessions.Session() request.session['person'] = 'identity' There are other views that access request.session['person'], e.g.: def do_something(request): return HttpResponse("Person: %s" % request.session['person']) 2. View a page or two within the next 30 seconds to 2 minutes, and request.session data will be {'person':'identity'}. Sometimes the request.session data lasts for an hour. Other times it disappears after seconds. 3. Mysteriously request.session becomes {} What is the expected output? What do you see instead? I would expect that request.session would not lose its information. What version of the product are you using? On what operating system? - Gae Utilities 1.3 - GAE Dev. 1.2.5 SDK - Django 1.0 (from get_version()) Please provide any additional information below. I note that after the session has disappeared _AppEngineUtilities_Session in GAE datastore contains a sid equal to the value of a gaeutilities_session cookie. There is nothing else in the datastore (i.e. no _AppEngineUtilities_SessionData) I'm afraid I'm just not using gaeutilities sessions properly, but I've tried everything I can think of so I think there is still something amiss, here. Is there any more information I could provide that may be of assistance? Thank you.

What steps will reproduce the problem? This is oversimplified, but essentially: 1. In Django Create a session likeso: from appengine_utilities import sessions Here is a Django view def signin(request): request.session = sessions.Session() request.session['person'] = 'identity' There are other views that access request.session['person'], e.g.: def do_something(request): return HttpResponse("Person: %s" % request.session['person']) 2. View a page or two within the next 30 seconds to 2 minutes, and request.session data will be {'person':'identity'}. Sometimes the request.session data lasts for an hour. Other times it disappears after seconds. 3. Mysteriously request.session becomes {} What is the expected output? What do you see instead? I would expect that request.session would not lose its information. What version of the product are you using? On what operating system? - Gae Utilities 1.3 - GAE Dev. 1.2.5 SDK - Django 1.0 (from get_version()) Please provide any additional information below. I note that after the session has disappeared _AppEngineUtilities_Session in GAE datastore contains a sid equal to the value of a gaeutilities_session cookie. There is nothing else in the datastore (i.e. no _AppEngineUtilities_SessionData) I'm afraid I'm just not using gaeutilities sessions properly, but I've tried everything I can think of so I think there is still something amiss, here. Is there any more information I could provide that may be of assistance? Thank you.

Earlier this year