feat: poc

[jannyHou]

Related to loopbackio#1952

Description see my comment below

Checklist

• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• API Documentation in code was updated
• Documentation in /docs/site was updated
• Affected artifact templates in packages/cli were updated
• Affected example projects in examples/* were updated

[jannyHou]

This PR is a PoC of the inclusion handler proposed by @batjos in comment.

Takes findById as an example method, after adding the code that fetches the included items, TodoList.findById(1, {include: [{relation: 'todos'}]}) returns

The PoC contains:

• A InclusionHandlerFactory is created to return a handler function that fetches the included items.

• When a relation is created, a corresponding handler will be registered in the source repository.

• TBD: retrieve the relation metadata in InclusionHandlerFactory function:

  • return different handler functions according to the relation type
  • find the fkName in the relation definition

• TBD(improve): Turn the factory to a class, each repository has a InclusionHandler class instance as property:

  • call this._inclusionHandler.register<TargetEntity>(targetRepositoryGetter) to register the relation handler.
  • call this._inclusionHandler.searchHandler(relationName) for each entry in the filter.include.

I also discovered a few problems worth discussion:

• The Filter interface is not designed to describe related entities, see its definition(and Inclusion's definition).

• I feel the inclusion handler's implementation would have overlapping code with relation repository's find method, I will investigate how to leverage those relation repositories when register the handler.

[bajtos]

@jannyHou

The Filter interface is not designed to describe related entities, see its definition(and Inclusion's definition).

Good catch, can you work with @raymondfeng to improve the type definition please?

We should eventually take a look at the JSON Schema/OpenAPI parameter schema emitted for filter too.

[bajtos]

This block of code will be repeated a lot, I'd like to see a simpler solution, e.g. a sugar API building on top of InclusionHandlerFactory.

Ideally, the entire block should collapse to a single statement, e.g.

this._registerInclusion('todos', todoRepositoryGetter);

Under the hood, the helper should look up the definition of todos relation to learn about the target model, keyTo, and any other metadata needed. See how _createHasManyRepositoryFactoryFor is implemented.

Also based on the code in juggler, every relation needs a slightly different implementation of the inclusion handler. Please include an example/acceptance test showing how to include models via belongsTo relation to ensure requirements of other relation types were considered.

[bajtos]

(see loopbackio#1352 (comment))

[jannyHou]

I added the belongsTo handler and it does fetch the parent instance for the child. BUT there is a problem when construct the returned data:

The Todo model only has property todoListId as the foreign key, but not todoList as its parent property. Therefore given the object

const todo = {
    id: 1,
    title: 'a todo item',
    todoListId: 1,
    todoList: {
      id: 1,
      color: red
    }
}

method toEntity(todo) won't convert property todoList and removes it in the constructed todo entity.

[bajtos]

It is important to consider the scenario where we want to fetch multiple source models and include their related models in the result, e.g. TodoList.find(1, {include: [{relation: 'todos'}]}). Under the hood, we must avoid SELECT N+1 issue. Inclusion handler must be able to fetch related models for multiple source-model ids in one query (using inq operator under the hood). The design proposed in loopbackio#1352 (comment) is already taking that into account, so does the existing implementation in juggler.

[jannyHou]

Good catch, can you work with @raymondfeng to improve the type definition please?

👌 Sure, will create another PR to fix it.