4 ms·

There are two ways to set up a one-to-many relationship. The first is to use an array that holds ids. The second is to use a more traditional db approach and cr

There are two ways to set up a one-to-many relationship. The first is to use an array that holds ids. The second is to use a more traditional db approach and create a separate mapping table where each document holds ids of documents its mapping. Use the former approach if your array will be relatively small (say, under ~2000 items). Use the latter if the number of relationships is much bigger than that. As far as compound indexes, we don't have support for that yet, but it will happen.

mintplant 14y ago
Good to hear that compound indexes are forthcoming. When you do have secondary index support, will there be functionality to enforce a "unique" index, or will that have to be handled application-side? Also, in your API documentation [1], I see there's an `append` function to add a value to an array. Is there an equivalent function to remove a value from an array? [1] http://www.rethinkdb.com/api/#js http://www.rethinkdb.com/api/#js
- jdoliner 14y ago
  Yes, you can do arbitrary slices on an array like in python such as: array[:5]. This is done using the slice command. I believe it's overloaded in python to work with it's native slice syntax.
- coffeemug 14y ago
  We can't commit to unique secondary indexes functionality. It depends on a number of technical decisions we are yet to make. We have a rough idea of the architecture, but we still have to work out the specifics, and uniqueness enforcement will depend on that.
jdoliner 14y ago
I think the latter approach is actually preferable in all cases in which you want to join the 2 (which is normally the whole point). The reason is that it makes it easy to use equijoin which won't work with arrays. So suppose I have table A and table B and table A-to-B describing their relationships. Table A-to-B has documents that look like: {a_id: "foo", b_id: "bar"} I can then say: table("A-to-B").eq_join("a_id", table("A")).zip().eq_join("b_id", table("B")).zip() And you'll get a document for each corresponding pair. If the ids are in an array then it's going to be a bit painful to write that query. (Although it can be done I believe). A future feature will probably be to make eq_join work with arrays of foreign keys.
- alexpopescu 14y ago
  > A future feature will probably be to make eq_join work with arrays of foreign keys. Nice!!!
alexpopescu 14y ago
There is also the completely denormalized solution of embedding all children into parents. This approach could work well when: - you don't access child documents directly - you don't update child documents too often - child documents are usually unique entities As you can see from the rules above, this would not be a good solution for the Store -> Categories -> Products (contradicts 1. and 3.) But it could work with models like Content -> Votes, Blog -> Comments, etc.

mintplant 14y ago

Good to hear that compound indexes are forthcoming. When you do have secondary index support, will there be functionality to enforce a "unique" index, or will that have to be handled application-side? Also, in your API documentation [1], I see there's an `append` function to add a value to an array. Is there an equivalent function to remove a value from an array? [1] http://www.rethinkdb.com/api/#js http://www.rethinkdb.com/api/#js

jdoliner 14y ago
Yes, you can do arbitrary slices on an array like in python such as: array[:5]. This is done using the slice command. I believe it's overloaded in python to work with it's native slice syntax.
coffeemug 14y ago
We can't commit to unique secondary indexes functionality. It depends on a number of technical decisions we are yet to make. We have a rough idea of the architecture, but we still have to work out the specifics, and uniqueness enforcement will depend on that.

jdoliner 14y ago

I think the latter approach is actually preferable in all cases in which you want to join the 2 (which is normally the whole point). The reason is that it makes it easy to use equijoin which won't work with arrays. So suppose I have table A and table B and table A-to-B describing their relationships. Table A-to-B has documents that look like: {a_id: "foo", b_id: "bar"} I can then say: table("A-to-B").eq_join("a_id", table("A")).zip().eq_join("b_id", table("B")).zip() And you'll get a document for each corresponding pair. If the ids are in an array then it's going to be a bit painful to write that query. (Although it can be done I believe). A future feature will probably be to make eq_join work with arrays of foreign keys.

alexpopescu 14y ago
> A future feature will probably be to make eq_join work with arrays of foreign keys. Nice!!!

alexpopescu 14y ago

There is also the completely denormalized solution of embedding all children into parents. This approach could work well when: - you don't access child documents directly - you don't update child documents too often - child documents are usually unique entities As you can see from the rules above, this would not be a good solution for the Store -> Categories -> Products (contradicts 1. and 3.) But it could work with models like Content -> Votes, Blog -> Comments, etc.