Ответ 1
Из http://developers.facebook.com/docs/reference/fql/stream:
Таблица потоков ограничена последними 30 днями или 50 сообщениями, в зависимости от того, что больше
Я хочу получить всю историю моей стены. Но я, кажется, попал в предел где-то еще в июне.
Я делаю несколько вызовов вроде этого:
SELECT created_time,message FROM stream WHERE source_id=MY_USER_ID LIMIT 50
SELECT created_time,message FROM stream WHERE source_id=MY_USER_ID LIMIT 51,100
и т.д.
Но я всегда оказываюсь на том же последнем (первом) посту на моей стене. Через facebook.com я могу вернуться гораздо дольше, поэтому у Facebook, очевидно, есть данные.
Почему я не получаю более старые сообщения? Есть ли другой способ очистить мою историю?
Из http://developers.facebook.com/docs/reference/fql/stream:
Таблица потоков ограничена последними 30 днями или 50 сообщениями, в зависимости от того, что больше
Теоретически это означает, что всегда увеличивая предел для соответствия смещению, он исправит его, но я не смог проверить это (я не уверен, являются ли проблемы, которые я вижу, другими ошибками в моем коде или если есть другие ограничения, я не понимаю о получении потока).
Кто-нибудь может объяснить, что я вижу, и что мне не хватает?
Вы можете воспроизвести мои результаты, перейдя в тестовую консоль FQL:
http://developers.facebook.com/docs/reference/rest/fql.query
вставляя в этот запрос:
SELECT post_id, created_time, message, likes, comments, attachment, permalink, source_id, actor_id
FROM stream
WHERE filter_key IN
(
SELECT filter_key
FROM stream_filter
WHERE uid=me() AND type='newsfeed'
)
AND is_hidden = 0 limit 100 offset 150
Когда вы нажмете "Метод тестирования", вы увидите один из двух результатов, которые я получаю:
Вам, скорее всего, придется поэкспериментировать, изменив значение "смещение", пока не найдет то место, где оно сломается. Только сейчас я нашел, что это ломается для меня в 155 и 156.
Попробуйте изменить лимит и смещение, и вы увидите, что пустые результаты не встречаются в определенном месте в потоке. Вот несколько примеров результатов, которые я видел:
Помимо просмотра отношения limit = offset * 1.5, я действительно не понимаю, что здесь происходит.
Пропустите FQL и перейдите прямо к графику. Я попробовал FQL, и это было ошибкой, когда дело доходило до пределов и получало заданные диапазоны дат. Вот адрес графика. Поместите свою собственную страницу facebook_id и access_token:
https://graph.facebook.com/FACEBOOK_ID/posts?access_token=ACCESS_TOKEN
Затем, если вы хотите, чтобы ваша история задала диапазон дат, используя since
, until
и limit
:
Эти даты начала и окончания находятся в unix-времени, и я использовал ограничение, потому что, если бы я этого не сделал, это дало бы мне только 25 штук. Наконец, если вы хотите получить информацию о своих сообщениях, вам нужно будет перейти к каждому отдельному сообщению и получить информацию для этого сообщения:
https://graph.facebook.com/POST_ID/insights?access_token=ACCESS_TOKEN
Я не знаю, почему, но когда я использую filter_key = 'others'
, работает LIMIT xx
.
Вот мой запрос fql
SELECT message, attachment, message_tags FROM stream WHERE type = 'xx' AND source_id = xxxx AND is_hidden = 0 AND filter_key = 'others' LIMIT 5
и теперь я получаю ровно 5 сообщений... когда я использую LIMIT 7
, я получаю 7 и т.д.
Как сказал @Subcreation, что-то с FQL в потоке с LIMIT и OFFSET, и более высокие отношения LIMIT/OFFSET, похоже, работают лучше.
Я создал проблему на нем Facebook http://developers.facebook.com/bugs/303076713093995. Я предлагаю вам подписаться на него и указать, что вы можете воспроизвести его, чтобы получить его в приоритетном порядке.
В ошибке я описываю, как простой поток FQL возвращает очень непоследовательный счетчик ответов на основе его LIMIT/OFFSET. Например:
433 - LIMIT 500 OFFSET 0
333 - LIMIT 500 OFFSET 100
100 - LIMIT 100 OFFSET 0
0 - LIMIT 100 OFFSET 100
113 - LIMIT 200 OFFSET 100
193 - LIMIT 200 OFFSET 20
Максимальное количество 1000 при использовании LIMIT FQL: SELECT user_id FROM like WHERE object_id = 10151751324059927 LIMIT 20000000
Вы можете указать created_time для своего запроса в facebook. Поле create_time - это время на основе unix. Вы можете преобразовать его с таким конвертером http://www.onlineconversion.com/unix_time.htm, или использовать программные методы зависит от вашего языка.
Шаблон, основанный на вашем запросе
SELECT created_time,message FROM stream WHERE source_id=MY_USER_ID and created_time>BEGIN_OF_RANGE and created_time>END_OF_RANGE LIMIT 50
И конкретный пример с 20.09.2012 по 20.09.2013
SELECT created_time,message FROM stream WHERE source_id=MY_USER_ID and created_time>1348099200 and created_time>1379635200 LIMIT 50
У меня есть аналогичная проблема, пытаясь загрузить старые сообщения с общедоступной страницы, добавив фильтр 'AND created_time < t 'и установка t для каждого запроса в minumum created_time, который я получил до сих пор. Странно, что для некоторых значений t это возвращает пустой набор, но если я вручную установлю t за один или два часа, я снова начну получать результаты. Я попытался отладить это, используя проводник, и дошел до точки, где определенный t получил бы мне 0 результатов, а t-1 получил бы результаты, и повторение дало бы мне такое же поведение.
Я думаю, что это может быть ошибкой, потому что, очевидно, если я создал_time < t-1 дает мне результаты, затем также created_time < t должен. Если речь идет о ограничениях скорости или правах доступа, тогда я должен получить ошибку, вместо этого я получаю пустой набор и только для некоторых значений t.
Мое предложение для вас - это фильтр на created_time и изменить его вручную, когда вы прекратите получать результаты.
Попробуйте с запятой:
SELECT post_id, created_time, message, likes, comments, attachment, permalink, source_id, actor_id FROM stream WHERE filter_key IN (SELECT filter_key FROM stream_filter WHERE uid=me() AND type='newsfeed') AND is_hidden = 0 limit 11,5