I wasn't the original poster but I was curious about your caution regarding class static fields.
Which Python framework are you using if you don't mind me asking? Jeff On Thu, Jul 29, 2010 at 10:49 AM, Tim Hoffman <zutes...@gmail.com> wrote: > Hi > > On Jul 29, 8:40 pm, Jeff Schwartz <jefftschwa...@gmail.com> wrote: > > Hi Tim. > > > > Help me out here 'cause I don't understand what problem you see with > storing > > a value in a static field? > > Wouldn't have a clue. I don't use java on appengine. You didn't > mention in your original > post you where specifically talking about java. > > In python class/module cached definitions last for as long as the app > instance is running. > > T > > > > > > > > As far as I know (and I am limiting my discussion here to Java and > servlets) > > objects are not persisted across http requests unless they are > serializable > > and stored in session or in memcache and that takes programming effort > > meaning you have to deliberately program the behavior. > > > > Yes there are statefull web frameworks such as Wicket and JSF for > instance > > that will persist objects accross requests without programming effort but > > even these are limited to model and view class instances for the most > part. > > > > As for classes (not instances) persisting across requests (and > eliminating > > those classes that are servlet and other server pluming classes) what > > classes are persisted across requests? > > > > If storing values in class static fields were problematic I'd guess that > > this would break quite a number of web apps. What do you think? > > > > Jeff > > > > > > > > > > > > On Thu, Jul 29, 2010 at 7:31 AM, Tim Hoffman <zutes...@gmail.com> wrote: > > > The biggest problem I see with storing the value at a class/module > > > level > > > is you really need to make sure you clean up after yourself, otherwise > > > the > > > value may still be set when the next request is processed and that > > > value may not be > > > appropriate. > > > > > I would personally always grab/cache values in request object, > > > memcache, and or session > > > as appropriate. > > > > > That way there is no danger of exposing data to other requests. > > > > > But hey, if you want to use module level caches go for it. > > > > > I have been running appengine projects ever since it was released and > > > started out with some > > > module level cache, and regretted it ever since. It was has proven to > > > be difficult ensure the cache > > > has been cleaned up, where as memcahce you can control out of > > > process. (You can't shut an instance down > > > if it has an error and you can't remove a value from a module cache) > > > > > Rgds > > > > > T > > > > > On Jul 29, 4:19 pm, Bill Edwards <twmaf...@gmail.com> wrote: > > > > Hey guys, > > > > > > Is it horrible to use global variables? I am currently executing a > > > > query at the beginning of my handler and storing the query result > > > > within class object A. I subsequently need to access the query > result > > > > within multiple different class objects, say B, C, and D. It has > been > > > > recommended to me to cache object A in the request object, but i need > > > > to access the variable from within various class objects, so I'm > > > > finding that I have to pass the object A in to the constructor for > > > > every new object i define, and then sync any changed state of object > A > > > > with the handler's version of object A when the various class object > > > > functions are completed. > > > > > > So it really seems like the simplest way to do things is to just > > > > define a global variable. Is there a better option? Can I think I > > > > would ideally want to create something liek a session object to store > > > > the global object. > > > > > > Thanks! > > > > Bill > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Google App Engine" group. > > > To post to this group, send email to google-appengine@googlegroups.com > . > > > To unsubscribe from this group, send email to > > > google-appengine+unsubscr...@googlegroups.com<google-appengine%2bunsubscr...@googlegroups.com><google-appengine%2Bunsubscrib > e...@googlegroups.com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-appengine?hl=en. > > > > -- > > -- > > Jeff > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to google-appeng...@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com<google-appengine%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- -- Jeff -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
