搜索 Facebook 用户的时间线
我正在执行此 FQL 查询来搜索我自己的时间线上的墙上帖子：
https://graph.facebook.com/fql?q=SELECT+message+FROM+stream+WHERE+source_id=me()%20AND+strpos(消息,'metalica') +>0&access_token=XXXX
（抱歉，链接看起来不太好）
这不是应该返回我拥有的包含字符串“Metallica”的所有状态更新吗？错误？较旧的帖子（1-2 岁）不会返回，这是因为：
流表的每个查询仅限于之前的 30 天或 50 个帖子，以较大者为准，但是您可以使用特定于时间的字段。例如，created_time 与 FQL 运算符（例如 < 或 >）一起检索更大范围的帖子。
I'm executing this FQL query to search the wall posts on my own timeline:
https://graph.facebook.com/fql?q=SELECT+message+FROM+stream+WHERE+source_id=me()%20AND+strpos(message,'metallica')+>0&access_token=XXXX
(Sorry for the link, it didn't appear nice)
Is this not supposed to return all status updates I have that includes the string "metallica"? Am I doing something wrong? The older posts (1-2 years old) don't return. Is this because:
Each query of the stream table is limited to the previous 30 days or 50 posts, whichever is greater, however you can use time-specific fields such as created_time along with FQL operators (such as < or >) to retrieve a much greater range of posts.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我读了一篇关于 Facebook 查询如何工作的博客文章 (http://developers.facebook.com/blog/post/478/)
举例来说，我查询
SELECT post_id, message FROM stream WHERE source_id=me() AND comments .计数> 50 LIMIT 10我相信最大限制是 5000，所以这将是您获得 Metallica 帖子的最佳选择。然而即便如此，Graph API 的可追溯性似乎还是有限的。有些人查看后发现，那里的帖子只能追溯到 2010 年，我无法超过 2009 年 4 月。也许我每年的帖子数量比其他人少，而且 API 的发布数量可能是基于帖子计数而不是基于日期店铺。
I read a blog article on how Facebook's queries work (http://developers.facebook.com/blog/post/478/)
Say for example I query
SELECT post_id, message FROM stream WHERE source_id=me() AND comments.count > 50 LIMIT 10I believe the max limit is 5000, so that'd be your best bet for getting your Metallica posts. However even so, the Graph API seems to be limited in how far back it goes. Some people have looked and found that posts only going back to 2010 are there, I cannot get past April 2009. Maybe I have fewer postings per year that the others and it might be post count based rather than date based for how much the API will store.