Michael-
Thanks for the clarification! Makes perfect sense.
Tres-
SqlAlchemy's ORM cache is limited to a session and within a transaction.
It also generates internal cache ids based on the primary keys, and only
works for selecting items via that key directly.
For example (in pseudocode)
data = session.query(A).options(joinedload('b'), joinedload('b.c'))
Generates internal cache ids for items based on:
A.id
B.id
C.id
Fetching the items directly will be a cache hit:
a = session.query(A).get(1)
b = session.query(B).get(1)
c = session.query(C).get(1)
however filtering the items will be cache misses:
a = session.query(A).filter(a.id=1, foo=bar)
I think calling a filter on ONLY the primary key will do a cache hit -- but
I could be wrong.
If you had a visibility/is_active toggle on your object, you would have to
make that column part of your primary key to use the internal cache with it.
Once you commit though, all objects are marked dirty and won't hit the
cache.
Once you have a new request/transaction, the session cache is cleared as
well.
On Monday, August 31, 2015 at 12:55:44 PM UTC-4, Tres Seaver wrote:
>
>
> Note FWIW that the traverser comes out of Zope-land, where the graph
> being traversed is in the ZODB, and hence heavily cached. BTW, I have
> been under the impression that the SQLAlchemy ORM already does some of
> that caching: am I wrong?
>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.
