FacebookのFQLストリーム制限？
壁の全歴史を知りたい。しかし、私は6月にどこかで限界に達したようです。
私はこのように複数の呼び出しを行います：
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件の投稿のいずれか大きい方に制限されます
私も同じことを経験しています。まったくわかりませんが、オフセットが制限* 1.5を超えることはできないようです。
理論的には、これは常にオフセットに一致するように制限を増やすことで修正されることを意味しますが、これを確認することはできません（私が見ている問題が私のコードの他のバグであるかどうか、またはあるかどうかはわかりませんストリームの取得について理解できないその他の制限）。
誰かが私が見ているものと私が欠けているものを説明できますか？
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
「テスト方法」をクリックすると、私が得ている2つの結果のうちの1つが表示されます。
- 結果が返されます：[{post_id： "926 ...（私が期待した）
- 空の[]を返します（私は予想していませんでした）
壊れた正確な場所が見つかるまで、「オフセット」値を変更して実験する必要があります。ちょうど今、155と156で壊れていることがわかりました。
制限とオフセットの両方を変更してみてください。ストリーム内の特定の場所で空の結果が発生しないことがわかります。これが私が見た結果のいくつかの例です：
- 「... limit50 offset 100」が中断し、空を返します[]
- 「... limit100 offset 50」が機能し、期待される結果を返します
- 「... limit50オフセット74」は機能します
- 「...制限50オフセット75」ブレーク
- 「... limit20オフセット29」は機能します
- 「...制限20オフセット30」ブレーク
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が言ったように、LIMITとOFFSETを使用したストリーム上のFQLには問題があり、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
Facebookクエリにcreated_timeを指定できます。 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
そして、2012年9月20日から2013年9月20日までの具体例
SELECT created_time,message FROM stream WHERE source_id=MY_USER_ID and created_time>1348099200 and created_time>1379635200 LIMIT 50
LIMIT FQLを使用すると、最大で1000のいいねが得られます。SELECTuser_idFROM like WHERE object_id = 10151751324059927 LIMIT 20000000
公開ページから古い投稿をダウンロードしようとして、フィルター 'AND created_time <t'を追加し、各クエリのtをこれまでに取得した最小のcreated_timeに設定しようとすると、同様の問題が発生します。奇妙なことに、tの値によっては空のセットが返されますが、手動でtを1時間または2時間戻すと、再び結果が得られます。 Explorerを使用してこれをデバッグしようとすると、特定のtで0の結果が得られ、t-1で結果が得られ、繰り返しても同じ動作が得られるようになりました。
これはバグかもしれないと思います。なぜなら、created_time <t-1で結果が得られた場合は、created_time <tでも結果が得られるからです。レート制限またはアクセス権の問題である場合は、エラーが発生するはずです。代わりに、空のセットを取得し、tの一部の値に対してのみ取得します。
私が提案するのは、created_timeでフィルタリングし、結果が得られなくなったら手動で変更することです。