Strong relations with referential integrity

[bajtos]

Essentially, we see two levels of relations:

• Weak relations, where the developer primarily wants to navigate related models (think of GraphQL) and referential integrity is either not important or already enforced by the (SQL) database.
• Strong relations, where the referential integrity is guaranteed by the framework together with the database.

IMO, referential integrity must be guaranteed at repository level (or lower). For example, when a test helper invokes repository APIs to seed the database with sample data, then we want the referential integrity to be preserved. If we implemented referential integrity at controller level, then consumers of Repository API would be bypassing these checks and would be able to created corrupted data.

Implementation wise, it's important to implement referential integrity in way that does not create any race conditions. For example, a naive implementation calling findById on the source model before creating a new instance of the target model creates a race condition - if another request deletes the source model instance after findById received database response but before create command is set, then we end up with corrupted data.

With SQL databases, referential integrity is typically implemented by defining FOREIGN KEY constraints. In the context of LB4, this means that lb4 migrate must create such constraints based on the relations configured by the app.

With NoSQL databases, users should use different relation types than hasMany, for example referencesMany or embedsMany.

[achrinza]

Just to quote from the other issue:

Unfortunately this isn’t universal across other connectors as LoopBack doesn’t provide a common interface. For example, the MSSQL connector doesn’t support this natively.

This may be a good opportunity to revisit this soon as it’ll help streamline the use of LoopBack 4 and promote an increase in overall efficiency of the SQL queries.

[stale]

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

[stale]

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.