📄️ Smart Nested Populate
MikroORM is capable of loading large nested structures while maintaining good performance, querying each database table only once. Imagine you have this nested structure:
📄️ Smart Query Conditions
When you want to make complex queries, we can easily end up with a lot of boilerplate code full of curly brackets:
By default, MikroORM will propagate all changes made to one side of bi-directional 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
JOINED loading strategy is SQL only feature.
By default, all entities are monkey patched with toObject() and toJSON methods:
📄️ Updating Entity Values
Updating Entity Values with assign()
📄️ 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 mongo), allowing to map any kind of results onto an entity. Such entities are mean for read purposes, they don't have a primary key and therefore cannot be tracked for changes. In a sense they are similar to (currently unsupported) database views.
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 EntityGenerator helper.
📄️ 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
To use migrations we need to first install @mikro-orm/migrations package for SQL driver or @mikro-orm/migrations-mongodb for MongoDB.
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.