docs: Opt out of "Unit of Work caching"

[zetti-caletti]

As @typeorm is sadly a dead project now, I was looking for other ORMs in the nodejs world and found Mikroorm.
In the docs I saw, that Mikroorm tries to return the entity from the cache (on second run) when queried by their primary key.
As nodejs are, compared to for example php scripts, long running processes, how does this behave if I have multiple nodejs processes/containers/servers running? If one process updates an entity and an other process/server queries for that entity and has it in his cache, then I am getting an outdated result. In the docs it says that you can specify your custom ResultCacheAdapter. I havent found a build in for Redis/Memcached, etc. Do I have to implement that by myself? Or is it best to completely disable the result cache (is possible?).
I found that MikroOrm has a RedisCacheAdapter, but it is listed under Metadata Cache, so it will not be used for Result Cache?
Thanks for answer and maybe the docs can be improved here a little bit. :)

[B4nan]

As nodejs are, compared to for example php scripts, long running processes, how does this behave if I have multiple nodejs processes/containers/servers running?

You are asking for more docs and it feels like you haven't read the current ones :]

https://mikro-orm.io/docs/installation#request-context
https://mikro-orm.io/docs/entity-manager#disabling-identity-map-and-change-set-tracking
https://mikro-orm.io/docs/identity-map#how-does-requestcontext-helper-work

In the docs it says that you can specify your custom ResultCacheAdapter

Feels like you are mixing identity map, result cache, and metadata cache, those are 3 different things. And yes, you need to bring your own cache adapters, MikroORM provides only one for memory (used for result cache) and one for JSON files (used for metadata cache). You can't configure the "identity map cache", that always lives in the memory, as that is tied to the EntityManager instance, you can't share it, it would break the change tracking. Note that the result cache is opt-in, you need to enable that on the call site, it is not enabled by default.

I found that MikroOrm has a RedisCacheAdapter, but it is listed under Metadata Cache, so it will not be used for Result Cache?

It does not have a RedisCacheAdapter, that is only an example of how you can create your own adapter. That class does not exist anywhere outside the docs.

[zetti-caletti]

I mean, whats the purpose of caching in Unit of Work if I should create a new cache (RequestContext) for every HTTP-Request?
Would be much better to have a shared/distributed cache like Redis (with user limited max amount of memory) and every process can use this cache to reduce database calls. And then remove the caching in Unit of Work completely.

[zetti-caletti]

Imagine we have two servers and a shared network cache:

Server 1 becomes a request:
/api/posts/1

Mikroorm always looks first in shared network cache (for example redis). There is not entry for Post with id 1. So it makes a database call and after that writes the result to the shared network cache.

Server 2 becomes a request:
/api/posts/1
Mikroorm always looks first in shared network cache and sees that there is an entity and returns that entity from the cache.

If an entity is deleted or updated, the entity in the shared network cache has to be updated as well.

[zetti-caletti]

The cache could look like this:

key: {tableName}_{primaryKey}
value: serialized entity

key: 'post_1'
value: {
    id: 1,
    name: 'Post One'
}

key: 'book_ea463a60-0f98-4464-97f9-af398ffc6fd8'
value: {
    id: 'ea463a60-0f98-4464-97f9-af398ffc6fd8',
    name: 'Book One'
}

[zetti-caletti]

I mean the idea of caching the things is very nice. But as far as I understand the whole cachiing mechanism only works if I have only one server/process running. If more, then things get broken, because the cache is local in memory and not shared.

[B4nan]

Please read those pages, again, more carefully, you still confuse identity map with result cache, those are two different things, with a different purpose. An identity map is supposed to be never shared, that is the whole point of it, as it guarantees only a single instance of a given entity exists in the context (usually a single request).

ResultCache only caches results from EntityManager and QueryBuilder calls, but not from Repository calls? Does this makes any sense?

Don't read too much between the lines. If you would open the repository docs, or even better, the code, you would see what a repository does - it only wraps EM. It works exactly the same, as it uses the EM to do everything.

But as far as I understand the whole cachiing mechanism only works if I have only one server/process running. If more, then things get broken, because the cache is local in memory and not shared.

And that is where you should put your redis cache adapter. For result cache it is indeed good idea.

I mean, whats the purpose of caching in Unit of Work if I should create a new cache (RequestContext) for every HTTP-Request?

To have single instance of a given entity in one context - to protect you from doing updates to a single entity (by its PK) multiple times, overriding each other. Don't think about it as a cache, it is not a cache per-se, it deduplicates entity instances to protect you from mistakes. It is rather a cache for entity instances, not a cache for querying database (that is exactly result cache).