Number primary key and hasAndBelongsToMany relationship

[vpanghal]

I have two tables (Usr and Album) with number as primary key. Usr table has one to many relation with Album table.

When I am creating this relation, I am getting this error message.

app:log ReqlLogicError: Expected type STRING but found NUMBER in: r.table("Album_Usr_member").insert(r.table("Usr").get(21578752).default(r.error("The query did not find a document and returned null."))("id").do(function(var_210) { return r.expr("30450912").do(function(var_211) { return r.object("id", var_211.add("_").add(var_210), "Usr_id", var_210, "Album_id", var_211) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }) })

I could not find much documentation but does thinky always require key to be string for one to many relation?

[vpanghal]

There was bug in my code where I was handing over primary key in string.

    r.expr("30450912").do(function(var_211)

After fixing this I am hitting this error

  app:log ReqlLogicError: Expected type NUMBER but found STRING in:
  r.table("Album_Usr_member").insert(r.table("Usr").get(26966288).default(r.error("The query did not find a document and returned null."))("id").do(function(var_1) {
  return r.expr(30450912).do(function(var_2) {
    return r.object("id", var_2.add("_").add(var_1), "Usr_id", var_1, "Album_id", var_2)
                          ^^^^^^^^^^^^^^
})

It seems addRelation is generating primary key of relation table by concatenating two primary keys with underscore. This will create String primary key. But rethinkDB somehow expect primary key to be NUMBER.

          return r.object(
            'id', rightKey.add('_').add(leftKey),
            model.getTableName()+"_"+joins[field].leftKey, leftKey,
            joinedModel.getTableName()+"_"+joins[field].rightKey,rightKey
          )

Is it known limitation?

[neumino]

Err, yes this is a known limitation, though we could fix it with adding .coerceTo("STRING"). The problem is that if people use are mixing keys (like numbers and strings), they will end up with collision, which seems pretty bad to me.

Maybe we should just add some doc about this limitation?

[brandon-beacher]

How about using an array of the index values, rather than a concatenation? Then the original datatypes would be preserved?

[neumino]

I think array were not allowed at some point, hence the concatenation. We could switch to array now, but that's a breaking change (people would have to migrate their data).