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.
Filter can be defined at the entity level, dynamically via EM (global filters) or in the ORM configuration.
Filters are applied to those methods of
condparameter can be a callback, possibly asynchronous.
There are three parameters you can use:
name- can be used to enable a filter on the query can also used to pass a parameter
cond- is the condition that should be added to the query when the filter is enabled. This can be a callback, even async
default- indicates if the filter is enabled by default on the query
You can define the
cond dynamically as a callback. This callback can be also
asynchronous. It will get two arguments:
args- dictionary of parameters provided by user
type- type of operation that is being filtered, one of
If we want to have a filter condition that do not need arguments, but we want
to access the
type parameter, we will need to explicitly set
otherwise error will be raised due to missing parameters:
We can also register filters dynamically via
EntityManager API. We call such filters
global. They are enabled by default (unless disabled via last parameter in
method), and applied to all entities. You can limit the global filter to only specified
Filters as well as filter params set on the EM will be copied to all its forks.
Global filters can be also registered via ORM configuration:
We can control what filters will be applied via
filter parameter in
We can either provide an array of names of filters you want to enable, or options
object, where we can also disable a filter (that was enabled by default), or pass some
parameters to those that are expecting them.
filters: falsewe can also disable all the filters for given call.
When populating relationships, filters will be applied only to the root entity of
given query, but not to those that are auto-joined. On the other hand, this means that
when you use the default loading strategy -
LoadStrategy.SELECT_IN - filters will
be applied to every entity populated this way, as the child entities will become
root entities in their respective load calls.
When toggling filters via
FindOptions, we do not care about the entity name. This
means that when you have multiple filters defined on different entities, but with
the same name, they will be controlled via single toggle in the