If you haven't used app engine, I would try out the datastore through Google
Big Tables first. It has limitations depending on your needs, but is
designed to disallow common inefficiencies -- common mistakes in database
design. I have found these much easier to use than SQLAlchemy, and the
"limi
Before you reinvent the wheel, do take a look at Celery (
http://celeryproject.org/
). I have been using it for all sorts of background/async processing
tasks ranging from sending emails to Twitter posting.
It was originally created in the Django world but can be easily
integrated with Pyramid, j
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
http://thesoftwarestudio.com/apex/options.html
apex.no_csrf =
OPTIONAL, a colon separated list of route names that should NOT be
subject to CSRF tests.
After a bit of back and forth with Pyramid and the way the event fires
off, a decorator with the current CSRF check won't work. I've got to
dig d
It sounds like the default permission is being applied to your HTTPForbidden
view.
Would setting permission=NO_PERMISSION_REQUIRED on the HTTPForbidden view
fix it?
Kai
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To view this discussi
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
On 16 October 2011 21:14, ravi teja wrote:
> Does response callback work for this? Should I use a messaging queue to
> provide the handling to another service?
You *can* use the transaction manager for this – it's possible to
attach a handler that's called after the response has been sent back.
17 matches
Mail list logo