Page Contents

Overview

Individual models are easy to understand and work with. But in reality, models are often connected or related. When you build a real-world application with multiple models, you’ll typically need to define relations between models. For example:

  • A customer has many orders and each order is owned by a customer.
  • A user can be assigned to one or more roles and a role can have zero or more users.
  • A physician takes care of many patients through appointments. A patient can see many physicians too.

With connected models, LoopBack exposes as a set of APIs to interact with each of the model instances and query and filter the information based on the client’s needs.

Model relation in LoopBack 3 is one of its powerful features which helps users define real-world mappings between their models, access sensible CRUD APIs for each of the models, and add querying and filtering capabilities for the relation APIs after scaffolding their LoopBack applications. In LoopBack 4, with the introduction of repositories, we aim to simplify the approach to relations by creating constrained repositories. This means that certain constraints need to be honoured by the target model repository based on the relation definition, and thus we produce a constrained version of it as a navigational property on the source repository. Additionally, we also introduce the concept of the inclusion resolver in relations, which helps to query data over different relations. LoopBack 4 creates a different inclusion resolver for each relation type.

Here are the currently supported relations:

The articles on each type of relation above will show you how to leverage the new relation engine to define and configure relations in your LoopBack application.

To generate a HasMany, HasOne or BelongsTo relation through the CLI, see Relation generator.

Limitations

Navigational properties of related models cannot be created, updated, saved, deleted or replaced, via the parent model. See its GitHub pull request.

Creating related models must be created separately after the parent model is created. See its GitHub issue.

Filtering by parent model

Where filters such as those used by model queries (create(), find(), replaceById(), and so on) cannot be used to filter a model by the value of its parent model. See its GitHub issue.

We don’t support recursive inclusion of related models. Related GH issue: Recursive inclusion of related models.

Splitting numbers of queries

It doesn’t split numbers of queries. Related GH issue: Support inq splitting.

Handling of MongoDB ObjectID type

It might not work well with ObjectID of MongoDB. Related GH issue: Spike: robust handling of ObjectID type for MongoDB.