The PoC implementation of belongsTo relation in #1618 proposed to modify the way how keyTo metadata of hasMany relation is inferred. Instead of creating keyTo from the source model name (Customer -> customerId), we can look for @belongsTo decorator to find the property used as the foreign key.
https://github.com/strongloop/loopback-next/blob/bcd7ee98cc4958ccde595cf26e35e6f53f236401/packages/repository/src/repositories/relation.factory.ts#L133-L146
This issue has two goals:
- Discuss whether it's a good idea to infer
keyTo from belongsTo metadata. Such change would require that hasMany comes always with belongsTo, while at the moment it's possible to use hasMany with no matching belongsTo.
- Implement the necessary changes. Either drop the current algorithm building
keyTo from source model name, or use it as a fallback if no belongsTo was found.
Important: making belongsTo required for all hasMany relations is a breaking change.
Acceptance criteria
TBD
The PoC implementation of belongsTo relation in #1618 proposed to modify the way how
keyTometadata ofhasManyrelation is inferred. Instead of creatingkeyTofrom the source model name (Customer->customerId), we can look for@belongsTodecorator to find the property used as the foreign key.https://github.com/strongloop/loopback-next/blob/bcd7ee98cc4958ccde595cf26e35e6f53f236401/packages/repository/src/repositories/relation.factory.ts#L133-L146
This issue has two goals:
keyTofrombelongsTometadata. Such change would require thathasManycomes always withbelongsTo, while at the moment it's possible to usehasManywith no matchingbelongsTo.keyTofrom source model name, or use it as a fallback if nobelongsTowas found.Important: making
belongsTorequired for allhasManyrelations is a breaking change.Acceptance criteria
TBD