It has been the first thing I thought but then I added in my template:
${hex(id(request.user))}
near items and it showed there was 2 threads returning contents
alernatively with a User instance each always with the same id.
In other words 2 User instances surviving through requests, each on
On 10/17/11 1:42 PM, neurino wrote:
Reading one more time Michael mail about the recipe:
> 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
*That's right the way I wanted it
Ok Michael,
thanks for confirming there's something wrong and simply I did not
misunderstood.
The problem is that, in a single thread, `request.user` *survives from
request to request* and is not affected by changes (like items deletion)
occurring in other threads until a `DBSession.refresh(reque
You would have to paste code to explain why your user object isn't
re-queried between requests, because that makes no sense. All the @reify
decorator does is cache the object "within a single request", it doesn't
affect other threads or other requests at all. All I can think of is that
you are eith
Reading one more time Michael mail about the recipe:
> 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
*That's right the way I wanted it to work!*
So why if I reload a page my
I already set up some template helpers on before render, I could add user
there but having it as a request attribute makes it available in all views
too.
I'm not using views as classes but defs, I'd prefer not rewriting them all
as classes
I'm reading Michael mail again and I assume one more time
-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
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 a
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
reque
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm personally not a big fan of this solution; I always store the bare
minimum in my sessions (makes it much easier to scale particularly if
you're throwing sessions into memcached if you have to load balance your
application) - if I *must* get the raw
Well seems adding
DBSession.refresh(request.user)
at the beginning of each view relying on `request.user` voids the
problem.
Now I wonder what's the benefit form having such attribute rather than
querying each time for it in views.
Thanks for your support
neurino
On Oct 17, 3:41 pm, neuri
I implemented the procedure [explained here][1] to always have a User
Object available as a request attribute.
It always worked good in development until I deployed it with Ubuntu -
MySQL
Using SQLAlchemy User object has a `items` relationship like this:
mapper(User, users,
propertie
12 matches
Mail list logo
