Slaves with query cache.. :+1:
Creating helper to make cache testing easier
When enabling/disabling query cache, make sure we are connected first
Merge pull request #188 from nickmarden/new-cache-middleware

When enabling/disabling query cache, make sure we are connected first
Dump query cache in a sharding-aware fashion.

This commit adds two features to query cache invalidation which
are not necessary in a single-database-connection world:

(1) It empties the cache each time enable_query_cache! is called
(typically once per request cycle), since it is not clear whether
the shard that was used for query caching in the previous request
will have a cache image that is consistent with the shard that is
being used for the current request.

(2) When a shard-invalidating event (currently defined as one of
:insert, :update, :delete) occurs, *all* shards will have their
query caches dumped rather than just the shard on which the update
occurred. This will provide consistent data images during the
lifetime of a single request, e.g. if the application tends to
request certain objects from a master database in some cases and
from its slave copy in other cases (for example: a master database
that is used for looking up users and slave database on which the
user and all of their related data is stored)
Merge pull request #191 from nickmarden/nick/sql-cache-bugfix

Dump query cache in a sharding-aware fashion.
Merge branch 'new-cache-middleware'