2

I am running the following FQL query, using the javascript api:

FB.api({
    method: 'fql.multiquery',
    queries: {
        'query1': 'SELECT source_id, actor_id, target_id, message, attachment, permalink, description, type, created_time FROM stream WHERE source_id IN (SELECT target_id FROM connection WHERE source_id=me() AND is_following=1) AND is_hidden = 0 AND type = 80 AND strpos(attachment.href, "youtu") >= 0 AND created_time < ' + unix_time,
        'query2': 'SELECT uid, name, profile_url, pic_square FROM user WHERE uid IN (SELECT actor_id FROM #query1)'
    }
}, 
function(response) { 
    console.log(response); 
};

It's supposed to return all youtube videos on the current users feed and allow repeat querying, by supplying unix_time (on first run, this is essentially NOW(), otherwise it's the oldest status time); which it does, buggy:

  • without setting a LIMIT (on query1): after ~3 queries, empty results are returned
  • LIMIT 100 or more (on query1): results are returned, but subsequent results are empty
  • when created_time < NOW(), results are returned (on multiple queries); otherwise the problem persists (created_time < time of oldest received status )

No errors are returned. I have *read_stream* permissions. I tried to find a related bug, but found only ones about FQL not returning all statuses.

arminrosu
  • 102
  • 11

1 Answers1

2

API results are spotty at best. Based upon my four+ years of experience with the Facebook API I've drawn my own conclusions as to how this is happening. Here's my bullet points:

  • Poor caching of data causing stale cache, cache misses, etc.
  • Different web servers in the cluster not in sync with the others
  • Different database servers in the cluster not keeping up with sync
  • Algorithm to fetch results is admittedly "unreliable" per blog: http://developers.facebook.com/blog/post/478/ You ask for 10 and it return 7 due to pre-filtering done wrong.

I would suggest caching the data from the API on your side, and keep union'ing in new data from Facebook so your UI can present more consistent data.

DMCS
  • 31,720
  • 14
  • 71
  • 104
  • Thanks! Caching server-side isn't really what I need. It seems just overkill (and I'm trying to do it all JS, as a personal goal). 4 years of facebook? kudos, I can barely stand the constant "hiccups" – arminrosu Mar 08 '12 at 14:51
  • Nah, it's not overkill. It is recommended that you do caching in order to alleviate too many API calls by your app. **Lowering the number of API calls while maintaining data availability is ALWAYS a good thing.** – DMCS Mar 08 '12 at 16:02
  • I thought the rules "required" me to accept only direct answers, not workarounds. Eventually I did it with fb.api and an increased limit, making this bug almost unnoticeable. Thanks DMCS! – arminrosu Apr 18 '12 at 06:58
  • An answer can be correct, even if it is not the answer the questioner is looking for. Such as a No answer, or "it's a known bug", or "yes, it is a limitation of the API", or "you're going to have to do a lot more work than you thought to handle the situation". Coding is hard and that's why we get paid the big bucks :) – DMCS Apr 18 '12 at 16:24