On Aug 25, 2010, at 10:47 AM, Michael Bayer wrote:

> 
> On Aug 25, 2010, at 9:37 AM, Nikolaj wrote:
> 
>> Hello,
>> 
>> I'm struggling to use the Beaker caching example in my project.
>> Accessing any attribute on an instance from cache triggers a load from
>> database of the instance - even trying to read the primary key!
> 
> that means the instances that you're putting in the cache are expired, or at 
> least those attributes you are attempting to read.    The beaker example 
> takes the objects from a result and sends them straight to the cache, but 
> does not detach them from the current session.  Therefore, if your backend is 
> the "memory" backend, the objects in the cache are the same as those in your 
> current session and they'll get expired when the session is committed or 
> rolled back.   
> 
> There's not a really spectacular way to get around that except to not use the 
> "memory" backend, use one that pickles like memcached (well, pretty much 
> memcached is the only backend I'd ever use, but the file/dbm file backends 
> would work here too).

well, this probably would work, this diff is against tip:

diff -r 568ef214c1ac examples/beaker_caching/caching_query.py
--- a/examples/beaker_caching/caching_query.py  Mon Aug 23 18:17:31 2010 -0400
+++ b/examples/beaker_caching/caching_query.py  Wed Aug 25 10:55:53 2010 -0400
@@ -63,8 +63,15 @@
            if particular attributes have been configured.
            
         """
+        
+        def createfunc():
+            items = list(Query.__iter__(self))
+            for item in items:
+                self.session.expunge(item)
+            return items
+            
         if hasattr(self, '_cache_parameters'):
-            return self.get_value(createfunc=lambda: 
list(Query.__iter__(self)))
+            return self.get_value(createfunc=createfunc)
         else:
             return Query.__iter__(self)
 

I've added a comment in the example regarding this.   




> 
> 
> 
> 
>> 
>> The beaker_caching example runs just fine on my system and doesn't
>> exhibit the same problems, although that's on SQLite and without
>> Pylons. I traced through the calls to session._merge and prop.merge
>> without luck, it seems to run through the column properties and merge
>> as expected.
>> 
>> How do I diagnose this, short of tearing my entire codebase apart? Are
>> there any instance state attributes I could inspect to see where the
>> merge is going wrong?
>> 
>> N
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "sqlalchemy" group.
>> To post to this group, send email to sqlalch...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> sqlalchemy+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/sqlalchemy?hl=en.
>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sqlalchemy" group.
> To post to this group, send email to sqlalch...@googlegroups.com.
> To unsubscribe from this group, send email to 
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/sqlalchemy?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Reply via email to