ungroup should return a stream if given a stream

[neumino]

If the table "test" has more than 100k elements, this is going to throw:

r.table("test").group({index: "date"}).ungroup()

Tackling a ungroup command at the end is useful if you want to rename some fields for example.

Not sure if it's a bug or a proposal. Feel free to tag and move to the appropriate milestone.

[coffeemug]

@mlucy -- what's the expected behavior in this case?

[mlucy]

This is possible in the specific case where you're grouping by an index, and I think we should support it. I'd classify it as a proposal because it requires new logic, it isn't a matter of just fixing broken behavior. Tagging as a proposal and putting in 1.14-polish.

[coffeemug]

From an API perspective I think this is clear, but putting in reql-discussion for bureaucratic reasons.

Does anyone object if we mark it as settled?

[mlucy]

No objections.

[mlucy]

Moving out of reql-discussion since it's settled.

[danielmewes]

This comes up quite a bit in user queries btw. I'm not sure if we'll have time to do this in 2.2, but we should try to not push this off too far.

[marshall007]

A workaround for this is to use distinct which emits the group values lazily and still allows the reductions to be performed across all shards. This is much faster than native group in every case I've tried:

r.table('test')
  .distinct({ index: 'date' })
  .map({
    group: r.row,
    reduction: r.table('test').getAll(r.row, { index: 'date' }).count()
  })

@danielmewes noted the only difference between this rewrite and .group(...) is that the distinct can result in empty groups if a document is modified while the query is being run.

[ChrisTalman]

Out of curiosity, has this been implemented in 2.4?