对于任何大于 2 的子查询,FQL 会变成蜗牛或超时。此外,我什至不确定是否选择了不同的 page_ids(每个用户都喜欢同一个页面,它是如何过滤的?)。因此,当您进行设置操作时,它很可能不起作用。只需执行两个查询。
- 一个得到朋友喜欢的 page_ids 列表的人
"SELECT page_id FROM page_fan WHERE uid IN (SELECT uid2 FROM friend WHERE uid1=me())"
- 然后另一个只是吸引你的喜欢
"SELECT page_id FROM page_fan WHERE uid=me())"
现在把它放在一个批次中,这样我们就可以一次获得两个数据集
fql?q={"userpages":"SELECT page_id
FROM page_fan
WHERE uid=me()",
"friendpages":"SELECT page_id
FROM page_fan
WHERE uid IN
(SELECT uid2 FROM friend WHERE uid1=me())"}
从这里你很可能有一个非常大的列表和一个小的列表
假设在 Python 中,
>>> len(data['data'][0]['fql_result_set'])
4505
>>> len(data['data'][1]['fql_result_set'])
85
我们需要在这里做两件事,
现在,就过滤器和 lambdas 而言,这最终将在这个级别上变得微不足道......但我们几乎破坏了数据的任何有用性。我们只有一组页面减去真正喜欢他们的实际朋友!我们如何验证?
好吧,现在考虑一下,最好不要让我们的 API 调用中的用户 id 字段,然后我们会将 id 聚集在一起。Python中的一个简单示例
>>> pages = {}
>>> for p in a0:
... for q in a1:
... if p['page_id'] == q['page_id']:
... pid = p['page_id']
... if pid in pages:
... pages[pid].append(p['uid'])
... else:
... pages[pid] = [q['uid']]
... pages[pid].append(p['uid'])
pages
会给我一个字典,每个键都有一个 id 列表作为值。
然后我们可以通过查看 API 调用和 crtl-F 的浏览器转储来确认。由于禁用 3rd 方应用程序的朋友的 API 隐私限制,查看实际页面将不是有效测试。我们希望匹配 JSON 响应中的出现。