Model relation: hasManyThrough

[dhmlau]

Open a separate issue to track hasManyThrough per request from @RaphaelDrai in
#2043 (comment)

Hello @bajtos,
It is important for us to have in LB4 the hasAndBelongsToMany (the direct many-to-many relation) that we are using in our LB3 application. We are actually in a transition process to move our LB3 application to LB4 and hasAndBelongsToMany is considered as an high priority.
May I suggest to have a new and separated case for the hasManyThrough in order to avoid confusion with this current case?

[clayrisser]

As suggested by @bajtos, I'm going to start working on the hasManyThrough before finishing the implementation of hasAndBelongsToMany.

#2308

[clayrisser]

I attempted to reimplement hasManyThrough using the hasMany relation with a through property. After implementing it, I now think it might not be the best approach. Below are some of the issues I ran into.

The hasManyThrough has to make a database query before creating a constraint. This forces the createHasManyRepositoryFactory to return an asynchronous function, which breaks the existing API.

https://github.com/codejamninja/loopback-next/blob/codejamninja/has-many-through-using-has-many/packages/repository/src/relations/has-many/has-many-repository.factory.ts#L66-L79

To keep backwards compatibility, I tried to make the createHasManyRepositoryFactory only return a promise if through is set. This allows the return type to be the following. I should mention that the following return type does give some errors currently.

HasManyRepository<Target> | Promise<HasManyRepository<Target>>

https://github.com/codejamninja/loopback-next/blob/codejamninja/has-many-through-using-has-many/packages/repository/src/relations/has-many/has-many-repository.factory.ts#L24

[clayrisser]

Another issue I ran into is the generics. hasManyThrough needs access to the through repository. This requires passing the repository type using generics, very similar to the way the target repository type gets passed through the generic.

export interface Through extends Entity {}

export function createHasManyRepositoryFactory<
  Target extends Entity,
  TargetID,
  ForeignKeyType,
  Through = Through,
  ThroughID = string
>(
  relationMetadata: HasManyDefinition,
  targetRepositoryGetter: Getter<EntityCrudRepository<Target, TargetID>>,
  throughRepositoryGetter?: Getter<EntityCrudRepository<Through, ThroughID>>,
) {}

https://github.com/codejamninja/loopback-next/blob/codejamninja/has-many-through-using-has-many/packages/repository/src/relations/has-many/has-many-repository.factory.ts#L45-L46

The challenge with this is that many times, hasMany is not using a through model and repository, so the through generic needs to be optional. This requires setting default generic values, and in my opinion is not ideal.

https://github.com/codejamninja/loopback-next/blob/codejamninja/has-many-through-using-has-many/packages/repository/src/relations/has-many/has-many-repository.factory.ts#L45-L46

Because the through generics are optional, this means they must be listed last. I would prefer the ForeignKeyType to be listed last.

This is why I think hasManyThrough should be defined in a separate relation altogether.

[clayrisser]

I would like to mention that using the hasManyThrough relation will be a little odd no matter how it is implemented because the constraint depends on asynchronous database queries. Using it will look something like the following.

Notice the two awaits

const patients = await (await this.physicianRepository.patients(physicianId)).find();

[clayrisser]

It would be great if ya'll could give me feedback on this.

[clayrisser]

I was just thinking, maybe the constraint for hasManyThrough could be built in the hasManyThrough repository (for example in the actual find method). This would most definitely require the hasManyThrough to be implemented as a separate relation.

[clayrisser]

Ok, so I actually was able to get hasMany to work in a fully backwards compatible way with a through property being passed into it. Basically, instead of getting the constraint in the factory function, I pass an asynchronous constraint getter into the repository.

https://github.com/codejamninja/loopback-next/blob/codejamninja/has-many-through-using-has-many/packages/repository/src/relations/has-many/has-many-repository.factory.ts#L55-L74
https://github.com/codejamninja/loopback-next/blob/codejamninja/has-many-through-using-has-many/packages/repository/src/relations/has-many/has-many.repository.ts#L92

Because I can do it with an asynchronous getConstraint function, I think I will be able to stick with implementing this in the hasMany repository. Currently, all the unit tests are passing in the following pull request.

#2359

[clayrisser]

This also fixes the double await issue.

[clayrisser]

I have a very basic example of hasManyThrough working.
https://github.com/codejamninja/medical-practice-api

You will need to use the code from the following remote and branch to get this to work.
https://github.com/codejamninja/loopback-next/tree/codejamninja/has-many-through-using-has-many

cd loopback-next/packages/repository
yarn build
yarn link

cd medical-practice-api
yarn link @loopback/repository
yarn start

    this.physicians = this.createHasManyRepositoryFactoryFor(
      'physicians',
      getPhysicianRepository,
      getAppointmentRepository
    );

https://github.com/codejamninja/medical-practice-api/blob/master/src/repositories/patient.repository.ts#L32-L36

  @hasMany(() => Physician, { through: () => Appointment })
  physicians: Physician[];

https://github.com/codejamninja/medical-practice-api/blob/master/src/models/patient.model.ts#L18-L19