You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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").
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: