-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pyramid has an awesome event system - you could easily setup an observer for any event after a request but before rendering that can query the DB and provide the user object.
Or you can go the base class view setup, I make all of my views classes that extend a base view class - the base view, on every request, gets the user's id from the session and provides a user object "self.user" that all extending classes have access to... You could even put it in a context object if you wanted. Michael said it right, re-read that email. neurino <neur...@gmail.com> writes: > What I guessed is my user attribute could be queried *once* *each time* a > page is _requested_. > > What I find is this does not happen as reloading a page — which happens to > be returned by a different thread than the one that operated on the > collection — user attribute is steady at a precedent state and *not > retrieved again* upon new request. > > Maybe I misunderstood the recipe but _why make a user available that way_ > also for *any* attribute that can be edited? > As far as I know usually only userid is immutable and it's already > available. > Every other property could lead to my same problem: user changes email then > he finds it unchanged in next profile page... > > So, is there an option for getting a new fresh user queried on each _page > request_ (honestly I thought it was the same as _request_ but I see it's > not)? > > @Parnell: I *do need* full user data in each page as I need to show user > items in sidebar. Choices. > > Thank you for your support > neurino > > > On Mon, Oct 17, 2011 at 7:24 PM, Michael Merickel <mmeri...@gmail.com>wrote: > >> Okay, I can't tell if you are misunderstanding that cookbook recipe, or if >> you made the decision independent of that to store the user object in your >> *session*. That is not what the recipe is advocating. It advocates a >> mechanism to query the user the first time you access that property of the >> request object and cache the result in memory for the lifetime of that >> request. >> >> Now if you decided that instead of querying the user from a database you >> would get it from a session then that's fine, but you need to understand >> that you are serializing a sqlalchemy object into a cookie. Thus when you go >> back to load that object from the cookie, you need to reconnect it with the >> database to make sure that it didn't change. This is done via the >> DBSession.refresh(). The point here is that either way is valid, but you >> *will* need to talk to the database once per-request if you want to use that >> object with SQLAlchemy. >> >> Another option is to only serialize the properties of the user that you >> care about, then you can use those directly without having to talk to the >> database. Then you're making the assumption that those properties didn't >> change in the background. >> >> >> -- >> >> Michael >> >> -- >> You received this message because you are subscribed to the Google Groups >> "pylons-discuss" group. >> To post to this group, send email to pylons-discuss@googlegroups.com. >> To unsubscribe from this group, send email to >> pylons-discuss+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/pylons-discuss?hl=en. >> - -- Parnell "ixmatus" Springmeyer (http://ixmat.us) -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJOnI34AAoJEPvtlbpI1POLXuoIAJ2QojCcV4VDh0Dm0WAZoavk 2owq3lQPZ4LUA6Ucsznv9opmHRYWJqQ4vbrEZ74H3+MYtLnWMAdxFB3q2Bq5NpK3 q5vtjUlmBJN3TpXjqryGJ5SFfk3oUS556GyHBYiYVRsLnOgVLgsj0uuv4zqKTapF HzpymB9AYw/FAA0p7mHMi5vtaOiHGgVAXilLtlgSyM1z9Ne+rmCCArQ4PMGJLVmW u5+qx46iJMna0sLXF/PxB35UJZfAAYzQa5VScaqbozxxF422lHddB8sXRCCfTbbB iSuzUWoSsxf5+ellOTnPzqKNpUo8PqwDE1unkJ86zl8nrhbO5giWkHkSblRgvkw= =QM6x -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
