Loopback-next: hasMany foreign key is not clear

[TomerSalton]

Description / Steps to reproduce / Feature proposal

I've been trying to define a hasMany relation step-by-step by the documentation.
I found it hard to understand what is the desired configuration regarding the foreign-key definition.

I have configured the source model and the source repository correctly.
I have created a designated controller correctly.

When trying to create a customer (the source model), I get the following error:

Invalid hasMany definition for Customer#orders: target model Order is missing definition of foreign key customerId

When I add the property 'customerId' in the target model everything works.

So far I understood two things:

1. The default foreign key is the sourcemodel+Id
2. I have to add the foreign key in the target model as a property (it's difficult to understand this from the documentation)

I would appreciate an approval that this is the desired behavior and configuration, and is not a bug.

Next, I have tried to change the KeyTo to another value, let's say "custId".
I did realize it does change the foreign key in the target-model relatively.
So far so good!

BUT, and here's where my unclarity from, I was trying to implement this relation when the target model has a strict: false setting (which means that the foreign key should be accepted even if not defined).
When the KeyTo is not defined -> failure.
When the KeyTo is defined -> success.

So, is there any difference in the logic between source models with and without KeyTo definition?

[pbalan]

To add to that. I think there's also some cache issue.

When I npm start and change the code or even if I closed the server and booted up, sometimes the dist directory didn't get the changes.

I had to manually delete the directory and run npm run build to generate the dist and get app started.

And this made me think that what I am doing is wrong...

[dougal83]

I had to manually delete the directory

That is why you have npm run clean. Needed for some changes.

[TomerSalton]

To add to that. I think there's also some cache issue.

When I npm start and change the code or even if I closed the server and booted up, sometimes the dist directory didn't get the changes.

I had to manually delete the directory and run npm run build to generate the dist and get app started.

And this made me think that what I am doing is wrong...

@pbalan I think I missed the connection to my issue.

[TomerSalton]

@bajtos Hey, could you help me clarify?

[danysz]

Have the same problem...in v4

[elv1s]

Is this a bug or a docs issue? Any more info around this will help other contribute back either a doc or bug fix.

[b-admike]

So far I understood two things:

1. The default foreign key is the sourcemodel+Id
2. I have to add the foreign key in the target model as a property (it's difficult to understand this from the documentation)

I would appreciate an approval that this is the desired behavior and configuration, and is not a bug.

Thank you for the issue @TomerSalton. Yes I believe the docs need to be updated to reflect the configuration of the foreign key on the target model. Both 1) and 2) are right. For 1), that is the default foreign key pattern we follow same as in LB3.

BUT, and here's where my unclarity from, I was trying to implement this relation when the target model has a strict: false setting (which means that the foreign key should be accepted even if not defined).
When the KeyTo is not defined -> failure.
When the KeyTo is defined -> success.

So, is there any difference in the logic between source models with and without KeyTo definition?

What were you trying to do that resulted in failure and what error did you see? Note that we don't automatically create/add the foreign key property in the target model definition and expect it to be explicitly defined on it (See https://github.com/strongloop/loopback-next/blob/master/packages/repository/src/relations/has-many/has-many-repository.factory.ts#L93-L97).

[b-admike]

@TomerSalton We've made improvements to our relation documentation recently at https://loopback.io/doc/en/lb4/Decorators_repository.html#relation-decorators which show how to define the foreign key property on the target model as well.

[dhmlau]

@TomerSalton @elv1s, do you think the recent change in the docs page: https://loopback.io/doc/en/lb4/Decorators_repository.html#relation-decorators helps? Thanks.

[elv1s]

Thanks @dhmlau; The docs give examples of using the first param EntityResolver<T> of the decorator. It might be helpful to have an example for using the optional definition Partial<HasOneDefinition> but the docs on relation describe this so it might be ok.

[dhmlau]

@elv1s, thanks for verifying that. Do you think you could contribute the missing piece (Partial<HasOneDefinition>) in the relation page?

[elv1s]

an example is already on the relation page, but I can make an update to the decorator docs as well.

[dhmlau]

Moving to 2019Q3 as this task is marked as help wanted.

[agnes512]

explanations and examples of customizing foreign key name are added to three relations. See https://loopback.io/doc/en/lb4/HasMany-relation.html#relation-metadata .