Apart from the public listings which are cached, queries in viewlets and
listings or any other part of Bungeni are not cached. There is a need to have a
consistent way of caching to be used everywhere in Bungeni. Sqlalchemy
supports caching through the use of the
Beaker[http://beaker.groovie.org/index.html]. Beaker can be configured to use
different kinds of caching backends such as files, memory and
memcached[http://en.wikipedia.org/wiki/Memcached].
In the example below from the ORM definition for parliamentary items, the users
table is queried and a User object created for every parliamentary item
returned by a query to the parliamentary items table
mapper(domain.ParliamentaryItem, schema.parliamentary_items,
polymorphic_on=schema.parliamentary_items.c.type,
polymorphic_identity="item",
properties={
"owner": relation(domain.User,
primaryjoin=rdb.and_(schema.parliamentary_items.c.owner_id ==
schema.users.c.user_id),
uselist=False,
lazy=False),
....
}
}
All queries to the parliamentary_items table would be much faster if User
objects were cached. The owner property would be changed to be a lazy loaded
property which is then loaded from cache. There are several relationships that
have "lazy=False" defined on them that would benefit from this change.
There is an example of this technique
here[http://www.sqlalchemy.org/trac/browser/examples/beaker_caching/caching_quer
y.py]. This could be implemented in such a way that all the queries in Bungeni
do not have to be modified.
For queries that would benefit from more aggressive caching, eg. for
parliamentary items in the workspace, queries would be changed to first query
the database for the id's of the relevant documents then check if they are
there in the cache, if not a database query is executed to get the item which
is then added to the cache.
Original issue reported on code.google.com by ashok.ha...@gmail.com on 15 Nov 2011 at 7:36
Original issue reported on code.google.com by
ashok.ha...@gmail.com
on 15 Nov 2011 at 7:36