Support multiple range query
We would like to narrow down the range so that it can be divided and synchronized, but it is not enough if there is only one range condition.
It would be great if we could narrow down it by two conditions by adding at least one more range.
For example,
* TimeRange & IntRange
At Some EC services: createdAt before 1 month AND price > 5000
- IntRange & IntRange
At Some graphic services: (500 >=
x> 0) AND (0 >=y> -500)createdAtbefore 1 month ANDprice> 5000
Query is like this:
collectionRef
.where("x", ">", 0).where("x", "<=", "500")
.where("y", ">", -500).where("y", "<=", "0");
It would be helpful as this could have the potential to reduce one's read operations.
Masahiro Yahara
shared this idea
It is now possible to have range and inequality conditions on multiple fields in one query.
Find the release notes here:
- https://cloud.google.com/firestore/docs/release-notes#March_27_2024
- https://firebase.google.com/support/releases#firestore-query-explain
And the documentation here:
- https://firebase.google.com/docs/firestore/query-data/multiple-range-fields
- https://firebase.google.com/docs/firestore/query-data/multiple-range-optimize-indexes
-
mohamed karim commented
Great thank for sharing
-
Finally, it's here!!! Amaaaazing!!
https://cloud.google.com/firestore/docs/query-data/multiple-range-fieldsI'm really happy about this.
I can only thank everyone who made this happen.
Now we can add various functions to our application! Thank you so much! -
CPH Bits commented
I totally agree. Firebase is really easy to use, documentation is simple and pricing model is transparent. However, I have decided to migrate to Azure due to this query limitation...
-
Developer Account commented
Totally agree with this. Opportunity for more complex querying would massively boost Firestore's capabilities IMO. I think I read somewhere once that it is to preserve Firestore's speed promises (I may be confusing with another nuance - apologies if so, it was a while ago since I was on that thread). However, if the business logic dictates that the complexity is necessary, then the speed still suffers by doing the same filtering client-side. I would rather sacrifice the query speed to have confidence in the quality of the data and leave all of the querying to the database rather than the frontend app.
-
Arrowhead Apps commented
Agree, the restriction of "a query can only have inequality/range filter on a single field" is highly restrictive. Quite an important feature that is missing.
-
I might clarify this to say "allow inequality filters on multiple fields", because I'm pretty sure you can have multiple inequality filters on the same field.