亲爱的Firebase爱好者,
我在Firestore上遇到多个查询问题 . 我正在为iOS开发 .
这是我想要查询的数据结构:
Collection X
- Document A
- date: 1532271987 (timestamp)
- users: {
- user_id_1: "true"
- user_id_2: "true"
- user_id_3: "true"
- ...
}
- Document B
- date: ...
- users: {
- ...
}
- Documents...
我想查询以下文件:
在 users
字典中包含 user_id_x
(如 users/user_id_x == true
)
AND
这是 date
大于 SOME_TIMESTAMP
这基本上是对同一API请求的多次查询 .
此外,我想按日期排序并限制获取项目的数量以启用分页,但这是我可以已经无缝管理,如下所示:
鉴于我知道我想要获取的项目 size
,以及 fromDate
timestamp参数
collectionReference
.order(by: "date", descending: false)
.whereField("date", isGreaterThan: fromDate)
.limit(to: size)
这很好用 .
在服务器端通过 user_id_x
参数过滤的内容是什么?所以我不能简单地使用以下内容:
collectionReference
.order(by: "date", descending: false)
.whereField("date", isGreaterThan: fromDate)
.whereField("users/user_id_x", isEqualTo: true)
.limit(to: size)
What I tried before:
1-
使用 /
使用 users/user_id_x
在这样的数据结构上访问user_id_x的方式应该根据文档工作,但我不能简单地使它工作..(使用 users.user_id_x
使用 .
来访问更深层次的简单崩溃在SWIFT上)
好吧,用户的结构不一定是这样的..它可以是一个数组(我知道它不是首选的查询..或者对象可以直接像这样:
- Document A
- date: 1532271987 (timestamp)
- user_id_1: "true"
- user_id_2: "true"
- user_id_3: "true"
- ...
但是,在这种情况下,Firestore必须为每个 user_id_x
present创建单独的索引,这对于顺便进行多次查询也不起作用 .
2-
我尝试创建连接索引(像Querybase这样的库背后的想法),例如:
- Document A
- date: 1532271987 (timestamp)
- users: {
- user_id_1: "true"
- user_id_2: "true"
- user_id_3: "true"
- ...
}
- date_user_id_1:"true_1532271987"
- date_user_id_2:"true_1532271987"
- ...
- date_user_id_x:"true_SOME_TIMESTAMP"
所以这个结构允许我查询类似的东西:
....whereField("date_user_id_x", isEqualTo: true_SOME_TIMESTAMP)
但这会获取与日期匹配的项目..为了查询类似的问题
....whereField("date_user_id_x", isGreaterThan: true_SOME_TIMESTAMP)
哪些查询 isGreaterThan
... Firestore抱怨(在控制台上)它必须在每个文档上创建名为 date_user_id_x
的索引..这必须在每次用户与时间戳相关时完成 . 我'm not sure how to automate that but it would be too much indexing job either.. Most importantly, I' m很丢失如何以我想要的方式完成这项工作 .
3-
Client Side filtering
是我想避免的事情..
所以背后的想法是,让我们从全局字典中提取10个项目,然后在本地设备上过滤它们,例如过滤项目是否为 user_id_x: true
. 但这对我正在研究的社交媒体应用来说是不切实际的,那里会有成百上千的用户 .
我试图避免它,因为它会积极地使用客户端网络,并且可能(很可能)导致提取没有与我们想要过滤的特定用户相关的项目(所以我必须 Build 一个机制,会再查询一次,直到它拉出一定数量的物品,这实际上太难以管理了 . 此外,我将根据结果获取图像数据,因此这里的任何错误都可能导致用户过多的数据消耗 .
4-711589_
所以我实际上可以创建另一个可以划分查询工作负载的字典 . 我可以先对用户进行过滤,然后使用日期,然后使用该字典的获取结果拉 Document_X
. 但这很难管理,因为我的应用程序中有近30个作业和案例导致 Document_X
, user_id_X
和 some_date
关系发生变化 . 将它们保存在一个字典中是很好的..但是在两个词典中管理它们只需要编写30个Google Cloud Functions,它们只会模仿第一个字典中的更改到另一个字典 . 这根本不实用 . 在我的第三次补偿功能之后,我一直走在那条路上而放弃了,因为我快速填写了Firebase上的数据使用配额(幸运的是我正在试用) .
Additional notes:
我查了一些其他的SO帖子,基本上解决了我上面提到的几个解决方案 . 我也深入研究谷歌论坛,并了解谷歌自2015年以来一直致力于此,但尚无结果 .
我认为应该有一个聪明的方法来做到这一点,很容易..我非常感谢你在这里的评论,想法和指导 .