Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
lb4 relations referential integrity for hasMany/belongsTo #1718
Description / Steps to reproduce / Feature proposal
As I was working on the user order history component for https://github.com/strongloop/loopback4-example-shopping I ran into an issue I thought LoopBack would've taken care of for me -- referential integrity with the
I am able to create an order using
Throw an error for an
For longer term, we can look into a better way to handle referential integrity. For now:
See Reporting Issues for more tips on writing good issues
This was referenced
Sep 24, 2018
referenced this issue
Dec 6, 2018
Defer the estimation until we figure out at which level are we going to apply the constraint.
In our recent discussion about HasOne's unique constraint for the foreign key, @raymondfeng @b-admike and me discovered a new way how to look at relations and constraints. Essentially, we see two levels of relations:
I think this issue (#1718) is applicable to Strong relations only.
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
In SQL databases, referential integrity is typically implemented by defining FOREIGN KEY constraints. In the context of LB4, I think this means that
For NoSQL databases, we can use optimistic approach:
Alternatively, we can also tell users to use a different relation type when using a particular NoSQL database, e.g. use
The difficult part is how to decide which approach to use for each database, and make it easy for users to know when they are using a relation that's not supported by their database. For example, a connector can print a warning when it detects that a model is trying to setup a foreign key or unique constraint.
For the scope of this particular GitHub issue, I am proposing: