fix(repository): revert hasOne target FK as PK implementation

[b-admike]

Remove attempt at guaranteeing the foreign key of a has one relation to be unique by using it
as the primary key of the target model. This allow users to set up their own unique contstraints. @RaphaelDrai FYI (what I mentioned in #2005 (comment))

Motivation:

@bajtos @raymondfeng and I had a discussion and since the memory connector and cloudant connector do not support unique indexes, we've decided to have the first release of hasOne provide "weak" relations i.e. ease of navigation and aggregation instead of enforcement of referential integrity and document it so users are aware of the limitations.

TODO: docs for the hasOne relation (most likely in another PR, so we can do a release).

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

[RaphaelDrai]

Hello @b-admike,
I understand that the change will guarantee the uniqueness relation from the source to the target but, the uniqueness of the relation in the opposite direction (from the target to the source) is upon the user decision, this is right?
If the answer is positive, can you please elaborate the two way configurations in the @model() for the user to guarantee or ignore the uniqueness from the target to the source direction?
I mean how to configure the @hasone and @belongsTo decorators in the @model().
Thanks.

[b-admike]

Hello @b-admike,
I understand that the change will guarantee the uniqueness relation from the source to the target but, the uniqueness of the relation in the opposite direction (from the target to the source) is upon the user decision, this is right?
If the answer is positive, can you please elaborate the two way configurations in the @model() for the user to guarantee or ignore the uniqueness from the target to the source direction?
I mean how to configure the @hasone and @belongsTo decorators in the @model().
Thanks.

Actually the changes do not guarantee uniqueness of the relation in any way, it is up to our users to set up the underlying database to be used instead of LoopBack doing so since we couldn't find a generic approach for it and need to investigate how to deliver a robust solution. You can find more info at #1718 (comment) and #2161.

[gczobel-f5]

But what about in-memory? In this case the is no DB...

[RaphaelDrai]

Hello,
What is the status of the missing implementation of DELETE and PATCH CRUD operations?
Thanks,
Raphael

[bajtos]

@RaphaelDrai Good catch! I think those two operations should have been implemented as part of #1422 but somehow that task slipped out.

Please create a new GitHub issue for this missing feature.

I am going to lock this pull request to collaborators only, please open new issues for any new discussions.