Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with composite keys #1295

Closed
brunocascio opened this issue Apr 9, 2015 · 9 comments
Closed

Problem with composite keys #1295

brunocascio opened this issue Apr 9, 2015 · 9 comments
Assignees
Labels

Comments

@brunocascio
Copy link

brunocascio commented Apr 9, 2015

I have this model:

{
  "name": "Like",
  "base": "PersistedModel",
  "properties": {
    "recipeId": {
      "type": "number",
      "id": 1,
      "required": true
    },
    "userId": {
      "type": "number",
      "id": 2,
      "required": true
    }
  },
  "validations": [],
  "relations": {
    "recipe": {
      "type": "belongsTo",
      "model": "Recipe"
    },
    "user": {
      "type": "belongsTo",
      "model": "User"
    }
  },
  "acls": [],
  "methods": []
}

and this SQL dump:

mysql> describe `Like`;
+----------+---------+------+-----+---------+-------+
| Field    | Type    | Null | Key | Default | Extra |
+----------+---------+------+-----+---------+-------+
| recipeId | int(11) | NO   | PRI | NULL    |       |
| userId   | int(11) | NO   | PRI | NULL    |       |
+----------+---------+------+-----+---------+-------+
2 rows in set (0.12 sec)

I found some errors when try to delete a model or getId.

Like.findById(1, function(err, like){
  like.getId() // this return only "recipeId" as id, bad.
})

Also, when destroying for example:

mysql> select * from `Like`;
+----------+--------+
| recipeId | userId |
+----------+--------+
|        1 |      1 |
|        1 |      2 |
+----------+--------+
2 rows in set (0.00 sec)
LikeModel.findOne({
                "where": {
                    "recipeId": rid, // 1
                    "userId": uid // 1
                }
            }, function(err, like){
                if (err) return fn(err)

                console.log(like) // here print { recipeId: 1, userId: 1 }

                like.destroy(fn); // this destroy ALL likes
            }); 

like.destroy(..) destroy ALL likes. I think it's related with getId(), because getIdName() only returned recipeId

@berill
Copy link

berill commented Sep 20, 2015

I'm also experiencing the same issue.

I have a model with the following properties:

"properties": { "userId": { "type": "string", "id": 1 }, "date": { "type": "date", "id": 2 },

and I'm trying to use findOrCreate:

const dayBlockId = {
      userId: userId,
      date: date,
    };
    const key = {
      and:
        [
          { userId: userId },
          { date: date },
        ],
    };
    DayBlock.findOrCreate(key, dayBlockId)

However, if I call multiple time the above code with same userId, but different date, the same DayBlock is returned.
As per the OP, calling getId() on the object return only the value of my first id column (i.e. userId)

@ericalves
Copy link

+1
the same problem.

@ericalves
Copy link

ericalves commented Aug 27, 2016

i saw persisted-model's source.. and the problem begin in getId() method.. because its return away one column!

PersistedModel.prototype.getId = function() {
    var data = this.toObject();
    if (!data) return;
    return data[this.getIdName()];
  };

@nelsonec87
Copy link

+1

1 similar comment
@perkd
Copy link

perkd commented Feb 8, 2017

+1

@bajtos
Copy link
Member

bajtos commented Apr 7, 2017

Possibly related: #2046

@bajtos
Copy link
Member

bajtos commented Apr 7, 2017

And also #126

@biruks
Copy link

biruks commented Nov 2, 2018

I am still seeing the issue. Even automigrate is not generating the right key combination table in the backend even if you define the model to be a composite key. FYI, My backend is SQL server database

@bajtos
Copy link
Member

bajtos commented Dec 6, 2018

I am afraid this is a limitation of LoopBack design and as such won't be fixed in 2.x/3.x versions. Please join the LoopBack 4 discussion here: loopbackio/loopback-next#1830

@strongloop strongloop locked as resolved and limited conversation to collaborators Dec 6, 2018
@bajtos bajtos closed this as completed Nov 12, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

9 participants