📄️ Filters
MikroORM has the ability to pre-define filter criteria and attach those filters to given entities. The application can then decide at runtime whether certain filters should be enabled and what their parameter values should be. Filters can be used like database views, but they are parameterized inside the application.
📄️ Deployment
Under the hood, MikroORM uses ts-morph to read TypeScript source files of all entities to be able to detect all types. Thanks to this, defining the type is enough for runtime validation.
📄️ 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).
📄️ Logging
For development purposes it might come handy to enable logging and debug mode:
📄️ 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.
📄️ Loading Strategies
MikroORM supports two loading strategies:
📄️ 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.
📄️ 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.
📄️ Events and Hooks
There are two ways to hook to the lifecycle of an entity:
📄️ Composite Primary Keys
Support for composite keys was added in version 3.5
📄️ Custom Types
You can define custom types by extending Type abstract class. It has several optional methods:
📄️ Virtual Entities
Virtual entities don't represent any database table. Instead, they dynamically resolve to an SQL query (or an aggregation in MongoDB), allowing to map any kind of results onto an entity. Such entities are meant for read purposes, they don't have a primary key and therefore cannot be tracked for changes. In a way they are similar to (currently unsupported) database views, and you can use them to proxy your native views already.
📄️ Embeddables
Support for embeddables was added in version 4.0
📄️ Defining Entities via EntitySchema
With EntitySchema helper we define the schema programmatically.
📄️ Using JSON properties
Defining JSON properties
📄️ Metadata Providers
As part of entity discovery process, MikroORM uses so called MetadataProvider to get necessary type information about our entities' properties.
📄️ Metadata Cache
In v4 and later versions, we need to explicitly install @mikro-orm/reflection to use TsMorphMetadataProvider.
📄️ Schema Generator
SchemaGenerator can do harm to your database. It will drop or alter tables, indexes, sequences and such. Please use this tool with caution in development and not on a production server. It is meant for helping you develop your Database Schema, but NOT with migrating schema from A to B in production. A safe approach would be generating the SQL on development server and saving it into SQL Migration files that are executed manually on the production server.
📄️ Entity Generator
To generate entities from existing database schema, you can use the EntityGenerator helper. It lives in its own package called @mikro-orm/entity-generator:
📄️ Naming Strategy
When mapping our entities to database tables and columns, their names will be defined by naming strategy. There are 3 basic naming strategies we can choose from:
📄️ Property Validation
Required properties
📄️ Migrations
MikroORM has integrated support for migrations via umzug. It allows you to generate migrations based on the current schema difference.
📄️ Seeding
When initializing your application or testing it can be exhausting to create sample data for your database. The solution is to use seeding. Create factories for your entities and use them in the seed script or combine multiple seed scripts.
📄️ 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.