Firebase-js-sdk: FR: Firestore OR operator in WHERE query

[EpicButterz]

[REQUIRED] Describe your environment

• Operating System version: N/A
• Firebase SDK version: 4.6.2
• Firebase Product: firestore

[REQUIRED] Describe the problem

Rather than having to make several separate queries I would like to see an OR operator for the WHERE query in Firestore. This is something that is currently available in MongoDB or with the $or operator here.

Relevant Code:

The query could look something like this:

citiesRef.where("state", "==", "CA", "||", "state", "==", "AZ")

or better yet

citiesRef.where("state == CA || state == AZ")

[EpicButterz]

For my specific case something more like an in operator would be more appropriate. I am looking to retrieve documents from a collection that correspond to a list of IDs. So something like:

citiesRef.in('id', ['P4ZoMnrNRQjnMGmuMmvc', 'VSw2KyP1YaBRnkheq5kB', 'i1658JL5a2Itv2l0BC8B'])

[agersoncgps]

OR and IN / CONTAINS / LIKE are pretty basic concepts in query languages. Confused why they are missing here.

[mikelehen]

Thanks for the feedback! These query improvements (OR, IN / CONTAINS, and LIKE queries) are all on our radar for future Cloud Firestore query improvements. I'm closing this issue as it's not specific to the JS SDK, but we know that these features would be very useful and there's a lot of demand for them. We intend to address them in the future as we continue to evolve Firestore's query functionality. Thanks!

[dzoba]

I would be very interested in these as well.

[andreluisce]

Any news about it?

[taishikato]

I am looking forward to this feature

[atcults]

Any news on ORing two filters ?

[csoreff]

I'd kill for a NOT IN [] >.<

[katothompson]

This would be a great feature to have!

[schassande]

I am looking forward to this feature too !

[jkampitakis]

Same here, I am looking forward to this feature.

[cnolimit]

can't wait to see the LIKE query addition

[mdrideout]

For anyone struggling for a solution, I mirrored the parts of firestore database relevant to search in elasticsearch. It's a search engine for no-sql database data, and can do WAY more than a "LIKE" or "WHERE" clause in a sql query. It's very customizable. Any additional data needed from the search results can then be pulled from firestore. In my app, elasticsearch handles any search queries, and data is pulled from firestore.

You can setup a stack on GCP relatively easily and for free, and now elasticsearch has their own stack deployment option (which can also use GCP, and provides more security options).
https://www.elastic.co/
https://bitnami.com/stack/elk

[githubbla]

I am looking forward to this feature too !

[rtman]

second all this.. OR is very necessary. Trying to concat lists after two WHERE queries is not great.

[troydcthompson]

Can't wait for this feature!

[m-a-zhou]

This feature would be very helpful.

[CyrusZei]

any ETA on this ?

[mikelehen]

We can't provide ETAs on upcoming features, but as I said before, OR queries and IN queries are definitely on our radar and we appreciate all the interest.

For what it's worth, IN queries are likely more straightforward and so we may tackle them first, something along the lines of what @EpicButterz described in https://github.com/firebase/firebase-js-sdk/issues/321#issuecomment-344994495. I'd be curious to hear how many of you would find that useful or if you're looking for more general-purpose OR queries. And if you're looking for more general-purpose OR queries, some details on your use cases (e.g. examples of specific queries that you'd want to do in your app) could help us design the feature. Thanks!

[csoreff]

@mikelehen IN and NOT IN are more useful I think. OR would be nice to have but for now we can just combine the results of multiple queries for that.

[mikelehen]

Thanks. I'm curious if there's a strong desire for "NOT IN" (against a list of values) or if just "!=" (against a single value) would be sufficient for the use cases you have in mind.

[csoreff]

@mikelehen Let's say I have a list of keys for ignored items. I'd like to be able to easily grab all items where the key is NOT IN []. != is certainly desired as well, but they have different use cases. Right now I'm forced to grab all items and then manually filter out the ignored items on client side.

[antonybudianto]

i want a datastore like this:

members: [
  {
    id: 123
  },
  {
    id: 231
  }
],

teams: [
  {
    id: 1,
    members: [123, 231]
  },
  {
    id: 2,
    members: [123]
  }
]

but because there's no IN query, I've to duplicate the relationship:

members: [
  {
    id: 123,
    teams: [1, 2]
  },
  {
    id: 231,
    teams: [1]
  }
],

/* teams remain the same **/

my requirement is that:
a user must be able to know his/her teams
and a team must know its members.

[mikelehen]

@antonybudianto Thanks for the feedback. If I'm understanding correctly, I'd actually characterize this as a slightly different feature and the good news is that:

1. You can solve this today by modeling your teams as { id: 1, members: { "123": true, "231": true } } and then for user 123 to find all their teams you can do a query like teamsCollection.where("members.123", "==", true).
2. We're looking into adding a new feature that would let you query based on array values which would let you keep your desired schema (with arrays) and do something like teamsCollection.where("members", "array_contains", 123). I can't promise any timelines but this may launch before we get to OR / IN queries.

[antonybudianto]

Thanks for the solution. But one more, suppose I visit the team "A" page, and want to display its members there (I want to display their names/other fields, not ids), how do you query it (userCollections should contains no relationship object because teamcollections already have it)?

[mikelehen]

@antonybudianto Ahh, yeah. To get a member's name, etc. you'd need to look that up from the members collection presumably. Cloud Firestore doesn't support JOIN operations and that's unlikely to change in the foreseeable future. That said, if we added an IN query as described in https://github.com/firebase/firebase-js-sdk/issues/321#issuecomment-344994495 then you could look up all the members with a single additional query once you have their IDs.

Thanks for the feedback.

[antonybudianto]

@mikelehen yes, IN operation will be sufficient for my case, thanks for the consideration.

[jorgevvr]

Hello all, i'm new here. So i am sad that have not some functionality that i can do with SQL but i hope that have soon.
This example mentioned by @mikelehen is exactly what i was searching for, hope it is added soon:

teamsCollection.where("members", "array_contains", 123)

Thanks!

[lxpdd]

Hello, I'm with team waiting a lot for such functionality as operators IN and NOT IN, it would improve performance of our application a lot.
Thanks!

[fguespe]

please do OR!

[wonsuc]

Since I noticed Firestore Security Rules doesn't support the enforce uniqueness of values across documents, I chose the way to search a document if it already exists with same values before I insert a new document from Cloud Functions.

This is my data structure.

logs: [
    1: {
        userId: "aaa",
        ip: "212.32.0.110",
        uuid: "00001101-0000-1000-8000-00805f9b34fb",
        timestamp: 1508249728426
    },
    2: {
        userId: "bbb",
        ip: "55.10.23.25",
        uuid: "00001101-0000-1000-8000-00a238b2d02e",
        timestamp: 1514802708503
    }
]

And here is a new document, which I'm trying to insert.

{
    userId: "ccc",
    ip: "212.32.0.110",
    uuid: "00001101-0000-1000-8000-001z21g29v0a",
    timestamp: 1514807874543
}

Now I have to query like this,
logsRef.where("userId == ccc || ip == 212.32.0.110 || uuid == 00001101-0000-1000-8000-001z21g29v0a")

In this example, it should return 1 result which has same ip value(=212.32.0.110) with new document.

I hope theOR query feature will be possible soon!
Please let me know if I'm doing something wrong or missing something :)

[natario1]

@mikelehen may I ask you something about your comment https://github.com/firebase/firebase-js-sdk/issues/321#issuecomment-380652617 ?

You state that the map approach is today's solution. But I don't get how we are supposed to leverage this for queries that are just a bit more complex: query.where("members.id1", "==", true).orderBy("createdAt"). This would need to create an index on member ids, so an index for each user. Obviously it is not affordable. How should this be tackled?

This came up in a super simple messaging app: conversation: { members: { id1: true, id2: true}} and I hope I am missing something, because it looks like the Hello World of databases. Do you have any clue?

If not, I hope that array_contains is not just in your radar but a high priority feature.

(By the way, this issue pops up pretty high in search results, so while I understand it should be closed, it would be cool if you could provide a link to a more appropriate resource where people can discuss (a google group post, ...))

[merlinnot]

@natario1 the simplest solution is to remove the inequality (orderBy or an inequality filter), you can sort it on the client side. You don't need custom indexes for this.

[natario1]

Thanks @merlinnot , but the collection might be large so we want to fetch small chunks with orderBy and limit and load the others as the user scrolls.

We also plan an additional constraint where(foo == bar), but I don't want to bother you with my specific use case, I think it is a common query / requirement overall.

[mikelehen]

@natario1 Thanks for the feedback. I can't provide concrete timelines, but array_contains has been under active development recently. If you poked at the commit history in this repo you might notice that the client-side support is mostly implemented. But we are waiting on the backend indexing / query support to roll out and unfortunately this could take some time (or in the worst case we could discover some blocker that delays the feature indefinitely). So I can't provide a concrete timeline, but the feature has been making progress. Hope this helps!

[mtnptrsn]

I'd love to see this feature!

[sumairrasool]

Wasted two hours because of not availability of OR/IN feature. :-(
And till now could not find a satisfactory solution except some performance leak solutions like querying multiple times or filtering data on client side.
Please guide me if you have any better solution for now.
Hope to see these features very soon.

[spiffytech]

I'd like OR so I can perform rudimentary substring searches. I'm happy to tokenize and stem my text and store that as document fields, but I'd need a way to query whether a document has any of the search terms.

[Elvis10ten]

Am still waiting for this.

[serrokitskiy]

Am still waiting for this.

[leonardoalcantara1]

Waiting ... ... ...

[lehno]

Waiting....

[IamSammyT]

I am very interested in the OR clause for the Android SDK as well.
I show tasks that are due today (or overdue) or have been completed today under 3 headings (Due Today, Overdue, Completed)
My sql query is like this: where nextDate <= today or lastDate = today

Something like this would be nice, so you can put:
any type of where clause inside the or
and more than 2 clauses

db.collection("tasks")
.or(
whereLessThanOrEqualTo("nextDate",today),
whereEqualTo("lastDate", today),
etc
)

[kshkrao3]

[adihat]

The reason OR queries isn't provided is very strategic from google. I may be wrong but this is my take on the subject => OR queries require the full scan of the database (or index in this case as they index every field by default) which may slow down the query speed and hence slow down fire store irrespective of whether they index every field or offer an option to create custom indexes.
Also its pretty evident that they wan't you to make multiple attempts to read the data and then concatenate it into a global array/list.
One of the solutions proposed was to use observables and merge the stream.
You can find one of the proposed solution (hacks if you will) for JS here =>https://medium.com/google-developer-experts/performing-or-queries-in-firebase-cloud-firestore-for-javascript-with-rxjs-c361671b201e

[ranjjose-chaz]

So, we have a very common _activities feeds_ requirement where each _activity_ can be tagged with multiple _interests_ . Users are advised to select their interests when they sign up. Now, without _OR_ operator, how am I supposed to list activties relevant to the users? If someone is having say, 5 interests, then it involves querying 5 times and then locally merging them (again sorting them probably based on timestamp). This will create complexities such as splitting the pagination limit across the _interests_, if there's not enough results in one interest then querying again on other _interests_ to compensate, etc.

I really wish Firebase doc upfront mentioning features such as OR, NOT, etc, aren't there. This is a very difficult situation.

[mikelehen]

Sorry for the pain. We know that this is a very large inconvenience, perhaps a blocker in some cases. To be clear, OR queries are on our roadmap. We can implement them efficiently without a full scan, at least in a large set of cases. There is a lot of work required though and I can't speak to the timeline.

In the meantime, doing multiple queries client-side and merging the results is the only workaround. I realize this is challenging, especially with pagination, etc. as @ranjjose-chaz mentions.

[cissecedric]

I think it could have been a good idea to clearly announce this point in the upfront doc (as said in a post before), so that developers won t feel like trapped once they ve mooved to firestore and discover it by themselves.

[IamSammyT]

@mikelehen Thanks for the update! The in clause is also on the roadmap? This should be an easier one to resolve?

[mikelehen]

@IamSammyT Yep, also on the roadmap. It could be easier to resolve if we treat it specially, but it may be more efficient for us to just implement "generic" OR queries at least at the low-level and have IN plug into that.

[gtcdevop]

One solution I came with, is to use Observable.forkJoin() and then join multiple firebase queries based on id

export interface Vendedor extends UsuarioInterface {
  filiado: [{ id: string, descontoPermitido: number, comissao: number }]; // email do escritorio vinculado
  comissaoAtual: number; // Se eu estou em déficit ou em saldo Positivo
  telefone: string;
  orcamentoCorrenteId: string;
  filiais?: any,// {filial1:true, filial2:true, filial3:true}
  nomeCompleto: string;
}

I was using id field to query on firestore and then join all the queries with Observable.forkJoin

Ps. I know that will increase the firebase usage but if you have not so many associations you may use this to countermeasure the problem.

[israelidanny]

waiting for OR and IN queries...

[markgoho-EDT]

Great idea for OR queries: https://medium.com/google-developer-experts/performing-or-queries-in-firebase-cloud-firestore-for-javascript-with-rxjs-c361671b201e

[israelidanny]

@markgoho-EDT it's neat, but only if you're using RxJS, and it doesn't really do OR, it still does two distinct queries behind the scenes.

[linq2js]

There is a package supports IN, OR operators and many more https://www.npmjs.com/package/linq2fire

[praveenkaraga]

@linq2js dose it support pagination query

[jkampitakis]

@linq2js this seems amazing! How exactly does it work?

[jahglow]

@linq2js darn you're a genius! I looked through your code and it seems to do the job.

[linq2js]

@praveenkaraga yes, it does
// support pagination
const pagination = linq(db)
.from('todos')
.orderBy({
text: 'asc'
})
.limit(1)
.where({
'text <>': 'Task 1'
});

await pagination
.get()
.then(printDocs('Find all tasks which has text not equal Task 1. Page 1'));

await pagination
.next()
.then(printDocs('Find all tasks which has text not equal Task 1. Page 2'));
await pagination
.next()
.then(printDocs('Find all tasks which has text not equal Task 1. Page 3'));

---

@jkampitakis I parse some special syntaxes and create multiple queries automatically
for sample, create 2 queries for OR operator, or create N queries for IN operator, it depends on Array item count:
.where({
// in operator
text: ['Task 1', 'Task 2'],
// or logic
or: {
text: 'Task 3'
}
})
for <> operator, I add 2 where conditions, one for "< value" and other for "> value"

[adihat]

support for array contains added: https://firebase.google.com/support/release-notes/js

[davidtlee]

@adihat it looks like array-contains is for querying a single value and getting all documents where an array field contains that single query value. It isn't for passing in an array and getting all entries that match anything in the query array.

[adihat]

@davidtlee Yup. Its Way better to have something than nothing😂
Pretty sure they will extend this but for now, this is what we have to work with.

[ahmadghufran]

Hi,
is IN feature available now?

[theicfire]

Doesn't look like it... OR, IN, or != would all solve my current problem

[linq2js]

array_contain is diff with IN
for sample, we use array_contain when
where book.categories array_contain A
using IN when
where user.type IN [admin, superadmin]
you can use https://www.npmjs.com/package/linq2fire ,it supports IN and OR operators very well

[jamesreilly5]

I appreciate the transparency with this issue from the engineers. I have a use case where I have the concept of "post" documents and then I track the "likes" that each individual user has. I could track those user ids in a userLikes array on the post document, but that means that as the number of likes increases then the size of the document downloaded increases.

The in operator would solve this perfectly for me, I hope the team make good progress soon on this. I know my users of my app will ask for this feature (seeing their liked posts) so I guess I might have to double up and store an array on the document for now. Looking forward to hearing updates, keep up the good work!

[mesqueeb]

+1 for != !

[DedicatedManagers]

+1 for != !

Very difficult to do multiple queries with onSnapshot callback function (and pagination). I want to get all documents not created by a user.

[linq2js]

linq2fire package provided != operator

[hristorv]

Is there any chance this will be implemented in the next update after 29 October (Firebase summit) ?

[wilhuff]

Even if there were some chance (and I'm not saying one way or the other), we can't comment publicly or commit to specific dates.

What I can say is that this is on our roadmap, but that we're currently prioritizing getting the product to GA over any new features.

[mesqueeb]

What’s GA ? I thought it meant Guardian Angel.
: D

[mikelehen]

General Availability. 😁 Right now Cloud Firestore is in beta which comes with some limitations and a lack of SLAs (service-level agreements).

[Motoralfa]

There is a package supports IN, OR operators and many more https://www.npmjs.com/package/linq2fire

Does the package do multiple query when execute IN, OR (numbers of query as conditions) or it is executed as an unique query?

[linq2js]

@Motoralfa It does multiple queries, but once firestore really supports IN, OR, it will update and your code dont need to update

[Motoralfa]

@Motoralfa It does multiple queries, but once firestore really supports IN, OR, it will update and your code dont need to update

Ahhh i undertand! Thank you so much for the explanation!

[pdemilly]

@linq2js Do you have a blog explaining how to use your lib. It looks like what I am looking for but sice there is no type definitions have difficulties starting using it.

[linq2js]

@pdemilly You can read somes here https://www.npmjs.com/package/linq2fire
I also add typescript d.ts file, it contains some small samples in comments. Please refer this https://github.com/linq2js/linq2fire/blob/master/index.d.ts

[linq2js]

let me check @Omar-Qalei , thank for your feedback

[vikas-patel]

Firestore pricing is based on number of documents read from back server. Supporting OR or IN operators firebase query means cutting down the document read. Don't think google will support it in future.

[jamesreilly5]

I think you're confusing it with requests. If you do a paginated request for 10 documents, you still get charged for 10 document reads. Someone correct me if I'm mistaken but I'm pretty sure that's correct

[samtstern]

Pricing is based on the number of results returned. So performing a single OR or IN query versus doing a bunch of individual queries and merging them yourself should cost the same amount.

[wilhuff]

@samtstern This is incorrect. Pricing is per-query, per-result, so if you submit multiple queries you're billed for each one independent of whether or not the results happen to overlap. In general Firestore pricing reflects the work the servers have to perform to satisfy the query. This ensures that the service is sustainable for us.

We are working on implementing disjunctive queries, and are doing so in a way that allows us to only read matching rows once. When it launches it should reduce the cost of this kind of query.

[samtstern]

@wilhuff is right, I oversimplified.

What I should have said (which is more direct) is this: our prioritization of this feature has nothing to do with trying to force developers to do more expensive, separate queries as @vikas-patel suggested. This feature requires extensive coordination across many parts of the Firestore team and right now the #1 focus is pushing the product out of Beta, then feature development will accelerate.

[vikas-patel]

@samtstern sound almost convincing.. but could be better if you do not hurry in charging customers and keep it free till it is beta..

[linq2js]

@Omar-Qalei linq2fire bug fixed in 1.0.18, please check

[linq2js]

@Omar-Qalei how you get that error ? please give me re-produce steps

[linq2js]

https://www.npmjs.com/package/linq2fire repo updated 1.0.18, dont know why you cannot fetch the latest

[linq2js]

may be you can change version of linq2file in package.json, then run "npm i" again

[linq2js]

@Omar-Qalei I assume that i runs from 0 to cities.name.length, so the query can be rewrite as

import linq from 'linq2fire';
const ref = this.afs.collection('Country');
const result = linq(ref).where({
  ...(this.cities.name ? {  name: this.cities.name } : undefined),
  ...(this.cities.area ? {  areaList: this.cities.area } : undefined),
}).get()

[linq2js]

@Omar-Qalei please show your code if possible, not defined is basic error

[linq2js]

please correct ".where({" and "}).get();" and you miss "..."(spread operator) before "(this.data.areaList ?" and "(this.data.propertyList ?"
Look at my sample code below

[linq2js]

import linq from 'linq2fire';
import * as firebase from 'firebase';
import 'firebase/firestore';

data = {
    areaList: '',
    propertyList: '',
  };
try() {
    const ref = this.afs.collection('AddListDataForRent');
    const result = linq(ref).where({
     ...(this.data.areaList ? {  name: this.data.areaList } : undefined),
     ...(this.data.propertyList ? {  areaList: this.data.propertyList } : undefined),
      }).get();
}

[linq2js]

just post updated code

[linq2js]

have no idea :(, you can upload your code to codesandbox if possible

[linq2js]

@Omar-Qalei
https://codesandbox.io/s/20ml7xvz3r here i my forked project
It seems the error does not come from linq, it is binding error

[samtstern]

@linq2js @Omar-Qalei please keep this thread on topic and don't use this as a place to debug your code! Limit posts here to discussions of the feature request only.

[linq2js]

@samtstern ok,
@Omar-Qalei I dont see the AjilunComponent in codesanbox project, please look at line 158 of that file, may be you try to use linq inside template file

[natario1]

I don't remember what tools are available, but can moderators please do something? I would like not to unsubscribe from this topic.

[samtstern]

@natario1 short of locking this issue, there are no tools. But it looks like @Omar-Qalei anad @linq2js are going to take their discussion elsewhere.

[vikas-patel]

I had build a social app on firebase 6 months back, initially I was showing all user posts ordered by recency in feed. As app has grown up now I want to prioritize friends post in feed (a very common use case), but this seems impossible in firestore.
Just to show top 10 results in user feed I need to fetch all friends posts (100 friends x 50 posts), rank the post and return top 10 ranked results. Imagine how slow it would be, making 100 connections from client app to server.
Another possilbity could be, prepare the individual user feed beforehand (fanout write) but this need too many writes and requires big storage.
I am thinking to dump firestore and migrate to mongodb. Is there any solution possible in firestore?

[Omar-Qalei]

@samtstern try use Number(Price) , I get specific object

[jeremyfrancis]

This seems like such a simple easy feature to add. What are we waiting for?

[Motoralfa]

@vikas-patel I was facing the same issue. I solve replicating the posts from Firestore to Algolia, and using both at the same time. Later, you can implement 'facetFilter' to retrieve all post created by your friends list.
I did something like that:
function searchPosts(freiendsArray) {
var that = this;
this.postIndex.search({
facetFilters: [friendsArray]
}).then(function (responses) {
that.searchResultsPosts = responses.hits;
});
}
where friendsArray is something like [{creator.uid:xxxxxxxxx}]

[vikas-patel]

@Motoralfa thank you so much for sharing your solution. As you mentioned replicating posts at another place is good idea. I am thinking in same line.

Thanks,

[akshayrangnekar]

I think you're confusing it with requests. If you do a paginated request for 10 documents, you still get charged for 10 document reads. Someone correct me if I'm mistaken but I'm pretty sure that's correct

Worth being aware - this depends on how you do the pagination request. As per Firebase docs, "...when you send a query that includes an offset, you are charged a read for each skipped document. For example, if your query uses an offset of 10, and the query returns 1 document, you are charged for 11 reads. Because of this additional cost, you should use cursors instead of offsets whenever possible."

[developerk786]

any news with "in" feature?

[linq2js]

@developerk786 you can use linq2fire package

[developerk786]

Jesus, =D one more dependency to my app =P, thanks @linq2js if possible could you please how do i do like this with that package:
Find All The Books Having Categories ["Physics", "Chemistry", "Biology"]
_And How does it do behind the scenes, does it make multiple queries or else?_

[jamesreilly5]

Can people please stop spamming this thread with discussions on other libraries? I'm subscribing to this thread because I want to know when this function will be supported. Please could you take other discussions to a private channel

[linq2js]

@developerk786
We can do this:
linq2fire(bookCollection).where({ category: ["Physics", "Chemistry", "Biology"] })
you right, It makes multiple query and join their results
actually linq2fire is just lib which contains many workaround methods for IN, startWiths, OR operators. When offical operators are implemented, I will update linq2fire and nothing to change for user

@jamesreilly5 currently, no offical support for this case, please help other people to solve their problems rather than saying something like: I dont like this, do not use this, dont do this blah blah. You dont need that but somebody elase need

[jamesreilly5]

@linq2js Look further up in the thread at all the comments that were marked as off topic and re-read the request from one of the actual google devs -

"@linq2js @Omar-Qalei please keep this thread on topic and don't use this as a place to debug your code! Limit posts here to discussions of the feature request only."

Please keep this thread about Firebase and not about linq2js.

[kkusanagi]

currently firestore only support "array-contains." as below.
citiesRef.where("array_state", "array-contains", "CA")

But it only valid for ONE argument. still not support for multiple.
And still not support for "array-not-contains".

Hope can add the features in future faster.

[mesqueeb]

I doubt they will. Like @mikelehen said when he closed this issue, the only thing on their radar is OR, IN / CONTAINS, LIKE.

If you need array-not-contains I think it's better to open a new issue.

[JerryBels]

Well, @mikelehen said it was on their radar, but... It's been more than a year and not a single one of these features appeared !

I don't want to sound bitter, but in a world where apps are evolving so fast programmers have to learn new things every month, more than a year is like eternity. Everyone who was interested in those features had to get the job done long time ago, by choosing a poor solution or another. It's actually the THIRD app I'm making that needs a in or a or and every time I have to come up with some fantasy solution when it should be straightforward, really.

For that, and for that only, when I will start my next app, I will check back here if something have been done. If it's not the case, I will handle my backend myself - using one of the few other solutions out there that needs a little more coding time but gives over more control.

[mikelehen]

@JerryBels Thanks for the nudge and for your patience. Your criticism is fair. I would have liked to have shipped OR queries by now. :-)

If you're interested in excuses, I'll say that Firestore is still a beta product and we've been consumed with a wide variety of improvements, many of which have been internal reliability / performance improvements rather than new feature development. In some cases we're also prioritizing features that unlock functionality for which there's no workaround. Since OR queries can often be emulated by doing multiple queries at once, we don't consider them to be blocking most apps from using Firestore. Obviously this isn't an ideal approach though and we know there's plenty of demand for proper OR query support!

So OR queries are still very much on our radar and we've made progress since the last time I commented, but I can't speak to any specific launch date. If we're not keeping up with your development needs, then please do find whatever tool best fits your needs right now, and if you're willing to check-in with us occasionally to see if we've caught up to what you need, that would be great. Thanks!

[JerryBels]

@mikelehen understandable, of course, thanks for answering and for your understanding. I hope it will be sooner than later ! Good luck and good work :)

[edi]

@mikelehen I guess that beta excuse doesn't work anymore :) So, given this is now a full fledged product, I would really like to see those happen. Speaking from the perspective of a paying customer, as I understand the majority of the users here are falling within the free tier. So, I would be a hypocrite to criticise something when I've never contributed.

Looking forward. I now have to start porting the entire app which I am just about to finish, towards firestore for scalability, better structure and more powerful queries. On the queries side, which is something Google really points out, we're still lacking, quite a bit, so I would have expected that to be sorted with by the time this was out of beta.

[bosung90]

We can't provide ETAs on upcoming features, but as I said before, OR queries and IN queries are definitely on our radar and we appreciate all the interest.

For what it's worth, IN queries are likely more straightforward and so we may tackle them first, something along the lines of what @EpicButterz described in #321 (comment). I'd be curious to hear how many of you would find that useful or if you're looking for more general-purpose OR queries. And if you're looking for more general-purpose OR queries, some details on your use cases (e.g. examples of specific queries that you'd want to do in your app) could help us design the feature. Thanks!

We have 2 properties, timestamp and status. We need to query all Orders that is today's timpestamp OR status is 'NEW'. Thanks!

[Omar-Qalei]

Anyone have a new solve ?

[edi]

@Omar-Qalei You can't solve it without changing your structure. So, until further notice, if you're using Firestore, do it as you would in Firebase. Or, use firebase.

No offence but on of the main selling points of Firestore is "powerful queries" ... and that really ain't true as of now. I'm really having a hard time deciding whether to port my app to firestore or not ..

[smholsen]

+1 for OR queries

[samstr]

+1

[uncvrd]

Would love this feature as well

[JStein92]

Pretty lame this isn't a feature, especially now that Firestore is out of Beta.

[mfferreira]

+1

[CyanDeveloper]

+1

[davidtlee]

@mikelehen What I really need is the "IN" case. The "OR" case is manageable just by doing two queries and handling it on the frontend. But "IN" is really needed for eager loading. If I am querying a collection and for each of those collections, I need to do separate queries (e.g. to get authors for each post), that opens up tons of connections. Having an "IN" query would enable that to be done with just two queries.

[timscullin]

+1 so essential

[long1eu]

Using "add reaction" on the initial comment would increase priority
while +1 comments
are rather pointless and cause lots of people to get notified for no reason.
To get notified yourself use the [Subscribe] button to the top right
instead.

On Sat, 23 Feb 2019 at 03:03, timscullin [e-mail] wrote:

+1 so essential

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/firebase/firebase-js-sdk/issues/321#issuecomment-466599003,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AI2nVkS057uP0Yo13I6tnGhVUoMYgyBjks5vQJNMgaJpZM4QgzlT
.

[efraespada]

+1 essential

[permadiberlianto]

+1, we need it

[CyrusZei]

could people please stop commenting on this and just add a Reaction instead?!?!

if you want this feature just add a 👍 on this comment and stop adding useless comments

[jeremyfrancis]

YES! Let's commit to terrorizing Firebase with our request for these features! Everyone like this post with a THUMBS UP and contact firebase directly!!!

[sam26880]

+1

[devpato]

The fact that this issue has 135 comments plus all the reactions and Firestore team hasn't done anything about it's alarming.

[Kinark]

@devpato True. +1 anyway

[thirajade]

this feature is truely needed

[awtmarriott]

come on, just copy the MONGO "Find" syntax...

[devpato]

Decided to open the exact same issue since they closed this one and haven't seen any reply from firebase latetly https://github.com/firebase/firebase-js-sdk/issues/1624

[rockwotj]

Hey all,

Backend features should be filed at Cloud Firestore's public issue trackers.

I took the liberty of filing two features based on this GitHub issue:

• One for the IN operator within filters
• One for the OR operator within filters

It'd be great if you could hit the star button if you're interested in one or both features. Additionally if you have a specific usecase that you think would be useful for Google to keep in mind when building this feature please put it there. You can also CC yourself there to get updates from the team - as @mikelehen already has pointed out, this GitHub issue tracker is for the JS SDK, and this feature needs support in the backend. I'd encourage you to file other new feature requests that are backend specific in that issue tracker too!

[davidtlee]

Where is the Me too! button? I went to the link for the IN operator and
don't see anything.

On Thu, Mar 21, 2019 at 3:01 PM Tyler Rockwood [e-mail]
wrote:

Hey all,

Backend features should be filed at Cloud Firestore's public issue
trackers https://cloud.google.com/support/docs/issue-trackers.

I took the liberty of filing two features based on this GitHub issue:

• One for the IN operator within filters
  https://issuetracker.google.com/issues/129056739
• One for the OR operator within filters
  https://issuetracker.google.com/issues/129070817

It'd be great if you could hit the Me too! button if you're interested in
one or both features. Additionally if you have a specific usecase that you
think would be useful for Google to keep in mind when building this feature
please put it there. You can also CC yourself there to get updates from the
team - as @mikelehen https://github.com/mikelehen already has pointed
out, this GitHub issue tracker is for the JS SDK, and this feature needs
support in the backend. I'd encourage you to file other new feature
requests that are backend specific in that issue tracker too!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/firebase-js-sdk/issues/321#issuecomment-475419709,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA0raSQm4AyngJRLZyKfhORxhyK9NP_Bks5vZAEtgaJpZM4QgzlT
.

--
David Lee
Website: tech4good.soe.ucsc.edu
Cell: [phone]

[rockwotj]

Sorry you actually have to hit the little star icon

[mesqueeb]

I humbly request all 81 participants of this thread (+158 persons who upvoted) to ⭐️ these issues, so that they can finally start looking into this!

[jeremyfrancis]

Hey all,

Backend features should be filed at Cloud Firestore's public issue trackers.

I took the liberty of filing two features based on this GitHub issue:

• One for the IN operator within filters
• One for the OR operator within filters

It'd be great if you could hit the star button if you're interested in one or both features. Additionally if you have a specific usecase that you think would be useful for Google to keep in mind when building this feature please put it there. You can also CC yourself there to get updates from the team - as @mikelehen already has pointed out, this GitHub issue tracker is for the JS SDK, and this feature needs support in the backend. I'd encourage you to file other new feature requests that are _backend specific_ in that issue tracker too!

Just starred it. Everyone take a minute to do the same please!

[darren-dev]

Anyone reading this, please go to the following links and click on the STAR icon at the left of the title:
https://issuetracker.google.com/issues/129070817
https://issuetracker.google.com/issues/129056739

[olshansky]

+1 _(sub for news and in the issue tracker too)_

[jamesreilly5]

Thank you for raising the issue @darren-dev, starred and commented!

[jamesreilly5]

Have raised another separate issue for NOT IN clause here - https://issuetracker.google.com/issues/129805446. Please star if this is blocking you too

[darren-dev]

@jamesreilly5 I may have a possible idea of a draft-fix, if you're open to entertaining the idea while your issue is there...

Basically, store the datePosted as a UNIX timestamp on each document, then on the user's end, each time they go to that page, update a field on the user such as dateSeen with the current UNIX timestamp.

Then you can easily do a where on the collection to only get the posts after a date (emulating only nre posts you haven't seen) such as

.collection('/posts').where('datePosted', '>=', user.dateSeen)

It's not perfect, but it's something :)

[jamesreilly5]

@darren-dev yes ideally this would work but my number of posts per day is not that many so the newer posts would be quickly exhausted. My total number of posts if high (enough) though so if I can keep them random enough it'll work. I'll either take the hit of querying again when duplicates are fetched or think about how I can better distribute my randomness (currently a value between 1 and 1,000,000). I have some ideas in mind. Thanks for the suggestion

[mpivchev]

Firestore devs: "Let's pretend this request doesn't exist"

[wilhuff]

We're quite aware that this request exists, and are actively working on making this happen. Unfortunately, nearly all the work to support this on the backend where it's invisible.

We'll update here when we have something to share.