loopbackio / loopbackio/loopback-next

Strong relations with referential integrity

Ouverte
#2,331 4 commentaires 1 réaction 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

epic Relations
Langage dominant
TypeScript
Étoiles
5.1k
Forks
1.1k
Merge moyen
2 j 21 h
PR mergées (30 j)
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.

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Commencez par suivre les API des repositories et le point d’entrée lb4 migrate du repository, puis examinez comment les relations configurées sont représentées pour les bases de données SQL. Comparez les contraintes FOREIGN KEY demandées avec les types de relations distincts suggérés pour les bases de données NoSQL. Le travail est terminé lorsque l’intégrité référentielle est appliquée sans conditions de concurrence sur les chemins de repository et de migration pris en charge.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
sql, typescript
Domaine
backend-api-design, databases
Type d'issue
Fonctionnalité
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
À l'abandon
Clarté
À clarifier
Accessibilité débutants
25/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.