ποΈ 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:
ποΈ Propagation
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.
ποΈ Serializing
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.
ποΈ 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 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
Required properties
ποΈ Migrations
To use migrations we need to first install @mikro-orm/migrations package for SQL driver or @mikro-orm/migrations-mongodb for MongoDB.
ποΈ 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.