Support for composite keys was added in version 3.5
MikroORM supports composite primary keys natively. Composite keys are a very powerful relational database concept and we took good care to make sure MikroORM supports as many of the composite primary key use-cases. MikroORM supports composite keys of primitive data-types as well as foreign keys as primary keys. You can also use your composite key entities in relationships.
This section shows how the semantics of composite primary keys work and how they map to the database.
ID fields have to have their values set before you call
Suppose you want to create a database of cars and use the model-name and year of production as primary keys:
Now you can use this entity:
And for querying you need to provide all primary keys in the condition or an array of primary keys in the same order as the keys were defined:
If we want to use the second approach with primary key tuple, we will need to specify the type of entity's primary key via
PrimaryKeyTypesymbol as shown in the
PrimaryKeyTypeis not needed when your entity has single scalar primary key under one of following property names:
id: number | string | bigint,
You can also use this entity in associations. MikroORM will then generate two foreign keys one for name and to year to the related entities.
This example shows how you can nicely solve the requirement for existing values before
em.persist(): By adding them as mandatory values for the constructor.
There are tons of use-cases where the identity of an Entity should be determined by the entity of one or many parent entities.
- Dynamic Attributes of an Entity (for example
Article). Each Article has many attributes with primary key
Addressobject of a
Person, the primary key of the address is
user_id. This is not a case of a composite primary key, but the identity is derived through a foreign entity and a foreign key.
- Pivot Tables with metadata can be modelled as Entity, for example connections between two articles with a little description and a score.
The semantics of mapping identity through foreign entities are easy:
- Only allowed on
primary: truein the decorator.
We keep up the example of an Article with arbitrary attributes, the mapping looks like this:
Sometimes you have the requirement that two objects are related by a
association and that the dependent class should re-use the primary key of the class
it depends on. One good example for this is a user-address relationship:
In the classic order product shop example there is the concept of the order item which contains references to order and product and additional data such as the amount of products purchased and maybe even the current price.
Internally composite keys are represented as tuples, containing all the values in the same order as the primary keys were defined.
This also applies when you want to get a reference to entity with composite key:
This part of documentation is highly inspired by doctrine tutorial as the behaviour here is pretty much the same.