See strongloop/loopback#2080 for the original discussion in LB 2.x/3.x.
LoopBack should support models using composite keys, where a primary key or a foreign key is composed from multiple properties.
Let's consider the following models as an example:
// A (GitHub) repository is identified by the pair [user, name]
// and has many issues
@model
class Repository {
@property({id: true})
user: string;
@property({id: true}
name: string;
@hasMany(() => Issue)
issues: Issue[];
}
// An issue belongs to a repository
@model
class Issue {
// how to specify @belongsTo relation?
}Functional areas we need to cover:
- How to define a model with a composite primary key (e.g. Repository above)?
- Connectors must understand composite ids and convert them to a concept the target database understands. SQL is easy because it supports composite primary keys OOTB, NoSQL like MongoDB and Cloudant can be tricky.
- create a new model
- find a model by id
- update (patch/replace) a model by id
- delete a model by id
- (etc.)
- Autoupdate/automigrate need to support composite primary keys too
- How to define composite foreign key in a model belonging to another model (e.g. Issue above)
- Relation repositories must work with composite keys
- How to expose a model with a composite primary key via REST API?
- How to expose a relation using a composite foreign key via REST API?
- Controller templates need to produce code that works with composite primary/foreign keys.
See strongloop/loopback#2080 for the original discussion in LB 2.x/3.x.
LoopBack should support models using composite keys, where a primary key or a foreign key is composed from multiple properties.
Let's consider the following models as an example:
Functional areas we need to cover: