4 ms·

Whoops, that's a great catch -- it's a bug in the docs. Will fix momentarily. Thanks!! (that is indeed embarrassing) In ReQL any command you call after `group`

Whoops, that's a great catch -- it's a bug in the docs. Will fix momentarily. Thanks!! (that is indeed embarrassing) In ReQL any command you call after `group` runs on each group. So once you've called `group`, you can run anything you could run on a table on each group and that just works.

meritt 13y ago
So, to be clear here, you have created two fundamental things (both called "filter") -- A pre-group and a post-group filter. Users must still understand the difference and when to utilize them. SQL just happens to call those WHERE and HAVING instead of "filter" both times.
- coffeemug 13y ago
  You're right, but it's not just `filter`. Any command that can run on a group can run on a full table and vice versa. For example: # get a sample of 3 elements from a table r.table('foo').sample(3) # get a sample of 3 elements from each group r.table('foo').group('category').sample(3) You could say that we created two versions of `filter`, and `sample`, and every other command. But another way to say it is that we use polymorphism, which is widely considered an advantage in modern programming languages.
  - meritt 13y ago
    Yeah, it's definitely more expressive and terse I just don't think your argument against WHERE/HAVING is incredibly strong. Someone could also just do subqueries and only use WHERE and achieve the exact same behavior that you offer (albeit with a ton more typing). HAVING exists because it was created prior to subqueries/dynamic tables, otherwise we'd have been likely to just use: select * from (select category, sum(num_comments) as comments from posts group by category) as temp where comments > 7
  - br1 13y ago
    As a LINQ user, I expected group('category').sample(3) to sample 3 categories, not to sample inside each category.
    - coffeemug 13y ago
      In ReQL you can do it with group('category').ungroup().sample(3). It's really powerful once you get the hang of it.

meritt 13y ago

So, to be clear here, you have created two fundamental things (both called "filter") -- A pre-group and a post-group filter. Users must still understand the difference and when to utilize them. SQL just happens to call those WHERE and HAVING instead of "filter" both times.

coffeemug 13y ago
You're right, but it's not just `filter`. Any command that can run on a group can run on a full table and vice versa. For example: # get a sample of 3 elements from a table r.table('foo').sample(3) # get a sample of 3 elements from each group r.table('foo').group('category').sample(3) You could say that we created two versions of `filter`, and `sample`, and every other command. But another way to say it is that we use polymorphism, which is widely considered an advantage in modern programming languages.
- meritt 13y ago
  Yeah, it's definitely more expressive and terse I just don't think your argument against WHERE/HAVING is incredibly strong. Someone could also just do subqueries and only use WHERE and achieve the exact same behavior that you offer (albeit with a ton more typing). HAVING exists because it was created prior to subqueries/dynamic tables, otherwise we'd have been likely to just use: select * from (select category, sum(num_comments) as comments from posts group by category) as temp where comments > 7
- br1 13y ago
  As a LINQ user, I expected group('category').sample(3) to sample 3 categories, not to sample inside each category.
  - coffeemug 13y ago
    In ReQL you can do it with group('category').ungroup().sample(3). It's really powerful once you get the hang of it.