3.0.*- where() inequality filter on multiple properties

[spoxies]

Having multiple 'inequality filters' on multiple properties isn't possible in Cloud Firestore. Therefore doing a query like bellow is not possible because GeoFirestore already does a filter on g.

geoInvites.near({'center': coordinates, 'radius': radius})
.where('date', '>=', new Date())

Prior to a certain issue I just happen to see and will not mention, GeoQuery.ts used startAt() internally. Thus allowing 'normal' where() queries.

Personally I use where() much more commonly/naturally. And if I'm correct the .near() interface currently does not allow for chaining .sort() and .startAt to solve this particular example/problem.

Could I purpose and would it make sense to revert src/GeoQuery.ts - 7beffe691588fa9db871cde3e95554624e141230 ?

[MichaelSolati]

Consider it on the table. I'm doing some work for the limit() function. So perhaps I can look at it over the weekend and have this addressed and limit() introduced to 3.1.0

[spoxies]

I did not realise that the change from where() to startAt() wasn't the solution for this example problem. Unfortunately this did not became apparent from the mocha tests, but only when implementing it as an actual (cloud) function. I like to apologise for my assumptions and noise, the PR proves not to be a "Fix" for this problem.

Example: geoInvites.near({'center': coordinates, 'radius': radius}).where('date', '>=', new Date())

Output: inequality filter property and first sort order must be the same: d.date and g

[MichaelSolati]

@spoxies darn, well this is something I'll have to explore still. I'll probably accept your PR and go from there (thank you)

[MichaelSolati]

So I've been doing some looking/tinkering/research an I don't think that this problem will be fixed. Because we have to do ordering on the g field we can't do ordering on other fields (no <, >, <=, >=) => see the Firestore docs

[luklew]

@MichaelSolati do you know what would be a good work around? I need to grab documents nearby based on a few criteria that require '>' and '<' but not sure what would be the best approach.

[MichaelSolati]

@luklew the filter withe geolocation and the added < or > would need to take place on client. You could do this on a cloud function if you didn't want to handle compute in the browser, but those are kinda your only options.

[luklew]

@MichaelSolati thanks for the answer, when you say on the client, does that mean basically get the nearest documents using .near(), then once the documents have been downloaded run them through a loop and do the filtering there?

[MichaelSolati]

@luklew yes... Probably not what you wanted, but it's the best that I can think of.