In MOBILE-3971 we introduced a new pattern to cache database tables in memory in order to speed up reads. After some investigation, we've seen that this approach won't be optimal in all the tables. For example, some tables have too many rows and the memory usage would be to high. Or some other tables don't make as many reads.

However, it's not completely clear what's the best caching strategy for each table without doing some real-life testing. Also, this could potentially become an issue in production. For that reason, we've decided to make database caching strategies configurable both on the entire app and on a per-table basis. This should be configurable with an entry in the config.json file.

In particular, we can create a database table manager that proxies database interactions through a cache following one of these strategies:

• Eager caching (what is already implemented in the config table, caching the entire table).
• Lazy caching (this would cache rows after being read once).
• No caching (this would just execute all the queries in the database without using any cache).

One candidate for using lazy caching is the filepool_files table. And the ws_cache_2 table will probably use no caching. The core_config table can continue using eager caching. So we can start by implementing the different strategies in these 3 tables.