loopbackio / loopbackio/loopback-next

Strong relations with referential integrity

Open
#2,331 4 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

epic Relations
Dominant language
TypeScript
Stars
5.1k
Forks
1.1k
Avg merge
2d 21h
Merged PRs (30d)
27

Description

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`.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the repository APIs and the lb4 migrate entry point, then inspect how configured relations are represented for SQL databases. Compare the requested FOREIGN KEY constraints with the separate relation types suggested for NoSQL databases. Done means referential integrity is enforced without race conditions across the supported repository and migration paths.

Written by the indexing model from the issue text.

Assessment

Tech stack
sql, typescript
Domain
backend-api-design, databases
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.