eqJoin method not found about rethinkdb HOT 9 CLOSED

@ptrln could you try equiJoin instead of eqJoin? I believe it's a bug in the JS client (the name has changed, but somehow I guess it wasn't updated). We'll fix it first thing Monday.

from rethinkdb.

yeap, equiJoin worked. However, when I run it I get this error:

> r.table('posts').equiJoin('user_id', r.table('users')).runp()
undefined
> { name: 'Runtime Error',
  message: 'Attribute: id is not the primary key (user_id) and thus cannot be selected upon.\n\tr.table(\'posts\').concatMap(function(arg0_1) {return r.let({\'right\':r.table(\'users\').get(r.letVar(\'arg0_1\')(\'user_id\'), \'id\')}, r.branch(r.letVar(\'right\').ne(r.expr(null)), r.expr([r.expr({\'left\':r.letVar(\'arg0_1\'), \'right\':r.letVar(\'right\')})]), r.expr([])))})\n\t                                                                                                                       ^^^^                                                                                                                                         ' }

But when I run the innerJoin version, it works fine:

> r.table('posts').innerJoin(r.table('users'), function(post, user) {return post('user_id').eq(user('user_id'))}).runp()
undefined
> { left: 
   { title: 'Google',
     url: 'http://google.com',
     user_id: 'peterlin',
     sub_id: 'news',
     post_id: '17af9cb1-e4e6-46b8-8963-fca62d059916' },
  right: { user_id: 'peterlin', name: 'Peter'} }

Is it because eqJoin can only be run on the primary key? The API docs isn't clear on this. I assumed "An inner join with a simple equality filter on the given attribute." means by two queries are equivalent.

from rethinkdb.

Confirmed that's the bug. @wmrowan -- could you change equiJoin to eqJoin in the JS client?

from rethinkdb.

@ptrln -- yes, that's correct, eqJoin only works when you're joining on the primary key of the right table (you can join on any attribute in the left table). Thanks for pointing this out, we'll clarify the docs together with this fix.

from rethinkdb.

So, I might be reading this wrong, but I believe the problem is that right now all the clients hard-code 'id' as the primary key in a few places, including as the key we select on for the right table in an eq_join.

At least in the Ruby client, the syntax here is that the first argument is the attribute we're selecting from the left table, and then we always use id as the attribute of the right table.

We should just fix this on the server, so that instead of hardcoding the id in the client that part of the protobuf is optional and it's filled in by the server as the primary key of the table.

A simpler client-only fix would be to reintroduce the optional third argument to eq_join, and let users specify the primary key of the right table there. This would also be forward-compatible when we introduce secondary indexes. I'll open a separate issue about that.

from rethinkdb.

@mlucy eq_join still has an optional third argument as best as I can tell (though it seems to be missing from the docs).

from rethinkdb.

Hm, it doesn't in Ruby. I'll fix that and update the docs.

from rethinkdb.

For this issue, we need to change the JS client from equiJoin to eqJoin, and add a third argument to the Ruby client. We also need to verify that the docs are correct on everything and have good examples.

For deeper server updates, I opened #29.

from rethinkdb.

This has been fixed.

from rethinkdb.