Implement result caching

[intellix]

Hey, more of a question. Within ORM there is 3 caches: Query, Result and Metadata.

I see in ODM there is currently only Metadata. Is there any plan to implement the other caches here or is it not required for ODM?

[solocommand]

Is there any plan to implement the other caches here or is it not required for ODM?

I'd like to know as well. I see that the Snc/SncRedisBundle has support (at least in semantic config, I didn't dig too deep into the code) for a doctrine document_manager for result caching.

The ODM Query class does not implement the setResultCacheDriver or setResultCacheLifetime methods, as in the ORM Query class.

Query caching makes sense in the ORM world where cycles spent generating complex joins and subqueries could be saved by storing the generated query, but in the ODM nothing like this really exists, aside from aggregation framework pipelines. Since aggregation queries bypass the QueryBuilder anyway, there doesn't seem to be a good place to cache these queries.

Result caching might not make sense for queries that return a cursor, but it seems feasible that it could be utilized for queries that return a single result, and could be beneficial for users wanting to implement a caching engine to retrieve documents.

I can look into hacking together an implementation, but I'm not sure how much time I'll have to devote to it.

[epicwhale]

@solocommand @intellix What's the suggested way to cache a Single ODM response Document for now? Any examples would be great (Even if using an external service / bundle).

I have Redis / SncRedisBundle, but still wondering what would be the right way to store the data in a REDIS key-val pair? Serialize?

[blockjon]

I would love to get some ideas on this topic as well.

[epicwhale]

Perhaps @jwage, @avalanche123, @jmikola, @kriswallsmith ... could point us in the right direction?

Presently, I am restricting myself only towards Varnish full page caching and in one-off cases, storing results of dehydrated documents / queries.

[solocommand]

@epicwhale Sorry, didn't see your question earlier. In the few places where we are using result caching, we're actually bypassing the document manager for the initial cache check. So something like

<?php
// ...
public function getDocumentById($id)
{
    if ($cacheKey = $this->getCacheKey($id)) {
        $document = $this->getDocumentFromCache($cacheKey);
        if (!$document) {
            $document = $this->getRepository()->findOneById($id);
        }
        return $document;
    }
}

At the moment, there isn't any way that I know of to accomplish single document caching utilizing the document manager.

[epicwhale]

@solocommand what are you using to save the document into a cache and retrieve it.. is serializing and deserializing a document safe?

[solocommand]

@epicwhale Now that I think about it, we aren't actually using this for doctrine results, sorry. I would imagine you would potentially run into errors if any references are unserialized, and likely the document would not be managed in the UoW after unserialization.

Sorry, the implementation I was thinking of was for caching external API responses (JSON docs) using redis, not directly caching single results from the ODM.

If you don't need to make changes to the document and don't need to deal with references a solution like that may work.

[coudenysj]

Any news on this?

[malarzm]

@coudenysj we haven't given it a thought yet (or I'm not aware of it). Personally I'm hiding DocumentManager in my own classes to which I can inject additional stuff (like Cache) - exactly what @solocommand written above. At the moment there are more important things (like PHP 7) so probably we won't devote time to the feature as of now... but we (or at least I) can offer some guidance if somebody would like to implement the caching :)

[coudenysj]

@malarzm I think some default caching options (as supplied in the ORM) would be a great addition the the mongo-odm repository. I think of read-only entities, result caching, etc...

I think I should start a separate ticket for this.

[malarzm]

@coudenysj :+1:

[manuelbcd]

+1

[coudenysj]

I started to play around with caching repository calls for a while, and the biggest hurdle is the Cursor object. Just a reminder when I start working on this :).

[alcaeus]

Just a heads up: the Cursor class will be vastly different in 2.0 once we're done with the migration to the new driver.

[manuelbcd]

May be we can implement the cache in the appropiate branch. @alcaeus could you tell me the branch of ODM focused on new driver?

[teseo]

looking forward to this!

[alcaeus]

@manuelbcd it took a little longer than I'd hoped, but your new target branch is master. It requires ext-mongodb and is the basis for the upcoming 2.0 release.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions.