Hi,
I do something like this to invalidate:
--code--
User.by_id(id, invalidate=True)
--code--
and on next request
c.user = User.by_id(id)
and no - regular query DOES NOT return right contents for me.
c.users = meta.Session.query(User).order_by(User.username).limit(30)
- this will only return
On May 7, 2010, at 12:41 PM, Ergo wrote:
Hi,
I do something like this to invalidate:
--code--
User.by_id(id, invalidate=True)
--code--
and on next request
c.user = User.by_id(id)
and no - regular query DOES NOT return right contents for me.
c.users =
On 7 Maj, 18:52, Michael Bayer mike...@zzzcomputing.com wrote:
expire_all() your session. that is why you are seeing your stale cache data
with a query that does not specify cache.
Was that added recently ? this happens on subsequent requests in
pylons application that in the end calls
On May 7, 2010, at 12:56 PM, Ergo wrote:
On 7 Maj, 18:52, Michael Bayer mike...@zzzcomputing.com wrote:
expire_all() your session. that is why you are seeing your stale cache data
with a query that does not specify cache.
Was that added recently ? this happens on subsequent requests in
This is only happening when one uses QueryCache?
Im completly lost now because back in 0.5.x i never saw a single
problem of this kind.
Every new request would use new correct data.
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this
the caching query example doesn't work with 0.5, so there's nothing to compare
with 0.5. The workings of the identity map have not changed.
On May 7, 2010, at 1:46 PM, Ergo wrote:
This is only happening when one uses QueryCache?
Im completly lost now because back in 0.5.x i never saw a
Im lost and clueless maybe im completly dumb :(
im trying really hard but i cant understand the problem.
every request calls meta.Session.remove() at the end of request - i
checked it does that.
Now even when i do:
meta.Session.query(User).order_by(User.username).limit(30)
I see the query
what happens when you rip out all cache code entirely ? you ceratainly need to
shut all of that off unconditionally before attempting to understand your issue.
On May 7, 2010, at 2:17 PM, Ergo wrote:
Im lost and clueless maybe im completly dumb :(
im trying really hard but i cant
ok, i THINK i understand whats going on... i reproduced it and i think
i understand whats going on since i was able to track the problem by
restarting memcache and noticing that it gives me right values:
its kinda deceiving at first, i do a request in application:
lets assume we have a users
it is 100% expected yes. its generally not a good idea to specify any caching
for a particular entity type in a particular request where you expect to be
getting fresh data from the DB for that entity type.
On May 7, 2010, at 2:37 PM, Ergo wrote:
ok, i THINK i understand whats going on... i
10 matches
Mail list logo
