📄️ Events and Hooks
There are two ways to hook into the lifecycle of an entity:
📄️ Cascading
Cascade merging is no longer configurable (and is kept enabled for all relations).
📄️ Serializing
By default, the ORM will define a toJSON method on all of your entity prototypes during discovery. This means that when you try to serialize your entity via JSON.stringify(), the ORM serialization will kick in automatically. The default implementation uses EntityTransformer.toObject() method, which converts an entity instance into a POJO. During this process, ORM specific constructs like the Reference or Collection wrappers are converted to their underlying values.
📄️ Result cache
MikroORM has a simple result caching mechanism. It works with those methods of EntityManager: find(), findOne(), findAndCount(), findOneOrFail(), count(), as well as with QueryBuilder result methods (including execute).
📄️ Dataloaders
The n+1 problem is when multiple types of data are requested in one query, but where n requests are required instead of just one. This is typically encountered when data is nested, such as if you were requesting authors and the name of their books. It is an inherent problem of GraphQL APIs and can be solved by batching multiple requests into a single one. This can be automated via the dataloader library which will coalesce all individual loads which occur within a single frame of execution (a single tick of the event loop) and then call your batch function with all requested keys. That means writing a batch loading function for every db call that aggregates multiple queries into a single one, plus filtering the results to reassign them to the original queries. Fortunately, MikroORM has plenty of metadata to transparently automate this process so that you won't have to write your own batch loading functions.
📄️ Streaming
If you want to process large amount of entities without loading them all into memory at once, you can use em.stream() method. It returns an async iterable, so you can use it in for await ... of loop.
📄️ Read Replica Connections
Users can specify multiple read connections via replicas option. You can provide only fields that differ from master connection, rest will be taken from it.
📄️ Propagation
By default, MikroORM will propagate all changes made to one side of bidirectional relations to the other side, keeping them in sync. This works for all relations, including M1. As part of the discovery process, all M1 properties are re-defined as getter/setter.
📄️ Property Validation
Required properties