doctrine/cache — pull request #17 by jmikola (2013-07-06 00:43:36+00:00)
Title: MongoDB cache provider

This supersedes #3. I implemented support for lifetime, reporting successful write operations (if acknowledged writes are used at the driver level), and reporting what little stats MongoDB can provide. Some things to discuss before merging follow below.

----

@guilhermeblanco mentioned [here](https://github.com/doctrine/cache/pull/3#):

> For non-flat cache structures, like Mongo, Riak, etc, maybe we should consider the namespace to define the exchange to be used. In this specific situation, exchange would be the collection. I don't know the exact thoughts on this, but if we only consider flat schemas, then either we should not support complex drivers or we would support cache only tied to a single exchange (and this patch proposal would be ok). The last one would lead us to allow multiple caches to be defined for each possibility (what we do in ORM, but maybe refine even more).

The existing namespace cache key template (`DoctrineNamespaceCacheKey[%s]`) is quite verbose. For MongoDB, we're storing the cache key in the `_id` field, which a perfectly logical place (it's the only field that gets uniquely indexed by default). Using long values for an `_id` simply wastes index space. If we did split things up by collections, we'd have the ability to flush individual namespaces, and not have all namespaces share the same index server-side.

----

One other thing I discussed with @guilhermeblanco in IRC was the behavior when a document is queried for `fetch()` or `contains()`, but we must report it has a miss due to a lifetime expiration. He suggested having that read method issue a delete internally, since we'd have no means of garbage collection otherwise (MongoDB's [TTL indexing](http://docs.mongodb.org/manual/tutorial/expire-data/) doesn't really help us here). The filesystem cache, among other backends that don't support TTL, should likely follow suit. Do we want to implement this behavior across the board for consistency?

----

The base tests are a bit sparse, and don't have any support for TTL behavior. Should that be improved in this PR, or should we deal with it later?

----

All of the tests appear to be functional. In MongoDB's case (and other OO drivers), we could get away with mocking the classes and doing actual unit tests for the cache provider. I assume there's not much point to that, though?