Using a changefeed with a geo intersection filter fails

[reidja]

When attempting to use an intersection filter in a changefeed the command fails:

Example command:

var bbox = r.polygon([25, 75], [75, 75], [75, 25], [25, 25]);
r.db('weather').table('metar').filter(r.row('location').intersects(bbox)).changes()

Error result:

RqlRuntimeError: Cannot call `changes` after a non-deterministic function in ...

Using rethinkdb 2.0.0+1 (ubuntu)

Would there be a way to force this command when you know your platforms are the same? (sort of like nonAtomic in updates?)

I'm willing to address this change with a pull request if someone could point me in the right direction?

[danielmewes]

Thanks for opening the issue @reidja.

@AtnNn, @reidja and I had briefly discussed this on IRC.

intersects is non-deterministic because it can give different results on different servers. However in contrast to some other non-deterministic operations (like accessing another table, or random operations), it is deterministic per server.

@mlucy do changefeeds like these actually require that the function is deterministic across servers?

If not, I propose that we make the non-determinism flag for terms more fine-grained to allow this.
We should also consider how this will interact with resumable changefeeds in the future, especially for the case where we support resuming a changefeed after an old primary has gone down.

An ignoreNonDeterminism flag might work, but we should understand (and explain) very well which consequences that can have. In the case of updates we can provide nonAtomic because we can actually fall back to an alternative processing scheme which maintains all guarantees, except for atomicity.

[danielmewes]

@reidja Here's a quick work-around if you're building from source (instructions: http://rethinkdb.com/docs/build/). Apply this patch to the branch v2.0.x:

diff --git a/src/rdb_protocol/terms/geo.cc b/src/rdb_protocol/terms/geo.cc
index 6c16acf..81a196c 100644
--- a/src/rdb_protocol/terms/geo.cc
+++ b/src/rdb_protocol/terms/geo.cc
@@ -207,6 +207,7 @@ public:
     intersects_term_t(compile_env_t *env, const protob_t<const Term> &term)
         : geo_obj_or_seq_op_term_t(env, term, poly_type_t::FILTER, argspec_t(2)) { }
 private:
+    bool is_deterministic() const { return true; }
     scoped_ptr_t<val_t> obj_eval_geo(
             scope_env_t *env, args_t *args, const scoped_ptr_t<val_t> &v0) const {
         scoped_ptr_t<val_t> other = args->arg(env, 1);

As long as you use a single server and you don't use intersects in a secondary index function (geo indexes and getIntersecting are ok), it should be safe.

[mlucy]

@danielmewes -- we can make it work as long as it's deterministic per-server. I agree we should make our notion of nodeterminism more granular to allow for this.

[danielmewes]

Ok sounds like we have a solution then. Assuming it's not super complicated, we should try to implement it for 2.1.

[reidja]

This is awesome, worked like a charm. Thank you @danielmewes

[knownasilya]

What's the status on this?

[danielmewes]

@knownasilya Sorry, no update yet. We're trying to get this into the 2.2.0 release, but I can't promise it yet (there are a bunch of other really important features that we're trying to get in as well).

[encryptio]

In review with @danielmewes, CR 3308