Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document hasMany/belongsTo/hasOne limitations for NoSQL databases #2340

Closed
4 tasks
bajtos opened this issue Feb 5, 2019 · 1 comment
Closed
4 tasks

Document hasMany/belongsTo/hasOne limitations for NoSQL databases #2340

bajtos opened this issue Feb 5, 2019 · 1 comment
Assignees
Labels
Docs feature Relations Model relations (has many, etc.)

Comments

@bajtos
Copy link
Member

bajtos commented Feb 5, 2019

Background

Cross-posting from #2127.

Our current implementation of model relations (has-many, has-one, belongs-to) is deeply rooted in SQL and based on the assumption that the database take care of referential integrity for us.

Example 1: "Customer has many Order instances" and "Order belongs to Customer". When creating a new Order instance, we expect the database to verify that Order.customerId is matching the id value of an existing Customer record. We don't have any reliable & atomic way to do this check at LoopBack side.

Example 2: "Customer has one Credentials instance". When creating a new Credentials instance, we expect the database to verify that there are no other Credentials instances already created for the user. We don't have any reliable & atomic way to do this check at LoopBack side.

SQL databases provide FOREIGN KEY and UNIQUE constraints that work great for this flavor of relations.

The situation becomes more tricky when we try to map this approach to NoSQL databases. Many NoSQL databases do not provide FOREIGN KEY and UNIQUE constraints, this is often a constraint caused by CAP theorem.

For example, it's not possible to enforce UNIQUE constraint when the model data is stored in multiple physical machines and a network partition occurs (a node performing a write operation is not able to reach other nodes because of networking problems, and thus is cannot verify that the new value is not violating uniqueness constraint for records stored on those nodes).

Goal

  • Treat 1-N relation as a concept that requires different implementation (schema design) depending on the database used. Explain this in our documentation for relations.

  • Make it very clear in our documentation that hasMany and belongsTo works best with SQL databases that are able to enforce referential integrity. When these relations are used with NoSQL, referential integrity is not enforced and we end up with a "weak relation"

  • In the docs for hasMany and belongsTo, explain NoSQL users that hasMany/belongsTo relations are not suited for NoSQL databases and that we are working on a better solution.

Acceptance criteria

  • Improve the main Relations page in our docs. Explain that for each relation (1-N, N-1, 1-1), there are different database schema designs available (hasMany, referencesMany, embedsMany). This is a good thing because each database paradigm comes with different trade-offs and thus different databases require the applications to use different relation types.
  • Improve HasMany page. Make it explicitly clear that this relation is intended for databases that support foreign key constraint. Explain what happens when this relation is used with databases that don't support this constraint (a "weak relation").
  • Improve BelongsTo page. Make it explicitly clear that this relation is intended for databases that support foreign key constraint. Explain what happens when this relation is used with databases that don't support this constraint (a "weak relation").
  • Improve HasOne page. Make it explicitly clear that this relation is intended for databases that support BOTH foreign key AND unique constraints. Explain what happens when this relation is used with databases that don't support this constraint (a "weak relation").
@dhmlau
Copy link
Member

dhmlau commented Apr 17, 2019

Closing as done.

@dhmlau dhmlau closed this as completed Apr 17, 2019
@dhmlau dhmlau added this to the April 2019 milestone milestone Apr 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Docs feature Relations Model relations (has many, etc.)
Projects
None yet
Development

No branches or pull requests

4 participants