[EPIC] Composite primary/foreign keys

See https://github.com/strongloop/loopback/issues/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.

Beginne mit der verlinkten Diskussion zu LB 2.x/3.x und dem Beispiel für das Repository/Issue-Modell. Der Umfang der Arbeit erstreckt sich auf Modelldefinitionen, Konnektoren, automigrate/autoupdate, Relations-Repositories, die REST-Bereitstellung und Controller-Vorlagen; als abgeschlossen gilt die Arbeit, wenn für jede aufgeführte Operation eine abgestimmte Unterstützung und ein testbarer Implementierungsplan vorliegen.