_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:
+1
+1
+1
@sneakyLance @evalenzuela @mathiasarens Posting +1 comments is rather unhelpful. Not only it spams people watching this issue with comments that are not much relevant, it also makes it difficult for us to see which issue as more popular than others. Please upvote the issue by pressing the 馃憤 button at the bottom of the issue description.

Upvoting this for visibility, as I am dealing with the same issue currently. It's a major need for any relational database as you stated. In lieu of native Loopback support (or until we get that), can't we just use a single primary key and define a new method which takes all entries in the database and does a dumb search to find the match for the second key? I'm relatively new to Loopback so forgive me in any conceptual shortcomings.
can't we just use a single primary key and define a new method which takes all entries in the database and does a dumb search to find the match for the second key? I'm relatively new to Loopback so forgive me in any conceptual shortcomings.
That may work for queries, but how would you go about enforcing uniqueness when creating new records?
I'm trying to do it using findorCreate and upsertwithWhere. However you are limited to POST requests, since you can't address the instance itself with PUT
I need to have a composite key made up of 3 columns, so the solution needs to be flexible, not just to handle two columns but as many as the developer requires.
What's the best workaround for this? Or are we stuck to denormalization?
Hi,
When we use a primary key as a string, when an object is created with POST method, the response is given with a number on the primary key instead of what we specified. Any reason/idea why ?
Just adding my 2 cents;
I think the basic implementation should be done as this is a common requirement in logical database designs with sub-types and weak entities where the IDs are not unique by themselves.
Any update on this?
We also need this.
Any update?
I spent a long time debugging my app before realizing this functionality wasn't supported :(
Even though it's possible to define a model that enforces uniqueness via 2 properties marked as id: 1 and id: 2, it won't support other database operations, like delete or update --> it simply fails with a "bad SQL message"
Any update on this?
Most helpful comment
I need to have a composite key made up of 3 columns, so the solution needs to be flexible, not just to handle two columns but as many as the developer requires.