2012-05-11 7 views
10

Ho scritto un piccolo script in JAVA, che verifica il parametro limit con quattro valori diversi (10, 100, 1000 e 10000) quando si interroga un feed di notizie di utente di Facebook utilizzando l'API Open Graph e RestFB client. Come vedrete, si ha un comportamento strano ...API Facebook Open Graph: comportamento strano del limite di parametri durante la ricezione di un feed di news utente impaginato

Scenario:

public static void main(String[] args) { 

    // vars 
    DateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); 
    FacebookClient client = new DefaultFacebookClient(accessToken); 
    Connection<Post> home; 
    List<Post> postList; 
    Map<String, Post> postMap; 
    int i; 

    // limits to test 
    String[] limits = {"10", "100", "1000", "10000"}; 
    for (String limit : limits) { 

     // init list and map (looking for duplicate posts) 
     postList = new LinkedList<Post>(); 
     postMap = new LinkedHashMap<String, Post>(); 
     // get news feed 
     home = client.fetchConnection(id + "/home", Post.class, Parameter.with("limit", limit)); 

     // going through pages 
     i = 1; 
     for (List<Post> page : home) { 
      for (Post post : page) { 
       // store into list 
       postList.add(post); 
       // store into map (unique post id) 
       postMap.put(post.getId(), post); 
      } 
      i++; 
     } 

     // sort posts by created time 
     Collections.sort(postList, new Comparator<Post>() { 
      @Override 
      public int compare(Post post1, Post post2) { 
       return post1.getCreatedTime().compareTo(post2.getCreatedTime()); 
      } 
     }); 

     // log 
     try { 
      FileWriter out = new FileWriter("log/output.txt", true); 
      out.write("LIMIT: " + limit + "\n"); 
      out.write("\tPAGES: " + (i - 1) + "\n"); 
      out.write("\tLIST SIZE: " + postList.size() + "\n"); 
      out.write("\tMAP SIZE: " + postMap.size() + "\n"); 
      out.write("\tOLDER POST: " + dateFormat.format(postList.get(0).getCreatedTime()) + "\n"); 
      out.write("\tYOUGNER POST: " + dateFormat.format(postList.get(postList.size() - 1).getCreatedTime()) + "\n"); 
      out.close(); 
     } catch (IOException e) { 
      throw new RuntimeException(e); 
     } 

    } 

} 

uscita:

LIMIT: 10 
    PAGES: 7 
    LIST SIZE: 56 
    MAP SIZE: 56 
    OLDER POST: 2009-03-22 14:58:03 
    YOUGNER POST: 2012-05-11 15:48:49 
LIMIT: 100 
    PAGES: 3 
    LIST SIZE: 174 
    MAP SIZE: 172 
    OLDER POST: 2012-01-12 23:01:34 
    YOUGNER POST: 2012-05-11 15:48:49 
LIMIT: 1000 
    PAGES: 2 
    LIST SIZE: 294 
    MAP SIZE: 292 
    OLDER POST: 2009-03-22 14:58:03 
    YOUGNER POST: 2012-05-11 15:48:49 
LIMIT: 10000 
    PAGES: 2 
    LIST SIZE: 294 
    MAP SIZE: 292 
    OLDER POST: 2009-03-22 14:58:03 
    YOUGNER POST: 2012-05-11 15:48:49 

Interpretazioni e domande:

  1. Ovviamente, non è possibile ottenere tutti i post che un utente ha avuto sul proprio feed di notizie da quando il suo account è stato creato. Il limite è limitato?

  2. Con una limit di 100, 1000 e 10000, devo aver avuto ogni volta due messaggi duplicati all'interno di tutta restituita news feed (174-172 = 194-192). Perché? Non ho mai visto lo stesso posto due volte sulla mia news feed personali ...

  3. Con (e solo con) un limit del 100, il post vecchio ottengo è stato creato durante l'anno 2012, nel frattempo gli altri valori di limit make la query che recupera un post che è stato creato durante l'anno 2009. Posso capire che con una superiore limit (1000 o 10000), la query recupera i post più vecchi. Ma perché lo a limit su 10 fa sì che la query recuperi un post più vecchio di una query limitata a 100?

  4. Ultimo ma non meno importante punto: Non ricevo lo stesso numero di post. Ovviamente, più il limit è alto, più il numero di post recuperati è alto. Quello che ho pensato per primo, è che l'unica conseguenza di un numero minore di limit era un numero superiore di pagine (il che è il caso), ma che il numero di post recuperati non sarebbe cambiato. Ma lo fa. Perché? Detto questo, il numero di posti sembra convergere tra una limit di 100 e 1000, perché il numero di posti identico ad un limit di 1000 e un limit di 10000.

PS: specificando un since e/o un parametro until alla query non cambia nulla.

Qualsiasi risposta/commento è benvenuto :)

Cin cin.

Edit:

Questo è il mio migliore recall:

LIMIT: 200 
    PAGES: 3 
    LIST SIZE: 391 
    MAP SIZE: 389 
    OLDER POST: 2012-01-27 14:17:16 
    YOUGNER POST: 2012-05-11 16:52:38 

Perché 200? È specificato ovunque nello documentation?

risposta

18

Non è nella documentazione, ma personalmente ho provato a seguire per il mio progetto.

Facebook limit è limitato a 500 post. Non importa che tu superi un limite superiore a 500, recupererà solo 500 risultati max. Prova con 500 (o più), riceverai i messaggi massimi.

Non si ottengono 500 post ogni volta ma si otterranno oltre 490 post in generale. Alcuni messaggi vengono filtrati da vari motivi (come la privacy, l'utente bloccato, non adatto per una regione specifica e altre cose)

Questo risponde alla prima e alla quarta domanda.

Per la domanda n. 2, non lavoro in Java, quindi non posso dire se c'è un problema nel tuo codice/logica o cosa sta facendo il tuo codice.

Per la domanda n. 3, Dio aiuta facebook!

Modifica

per il 4 ° problema, si può essere colpendo il limite di query/ora di grafico api (facebook lo usa per prevenire lo spamming, la tua ricerca non posso API di frequente in rapida successione)

Inoltre,

Facebook filter

questo è il motivo per cui, non si ottiene tutti i risultati restituiti da facebook.

(se è stato specificato un limite di “5”, ma i cinque messaggi restituiti non sei visibile allo spettatore, si otterrà un set di risultati vuoto.)

Oltre ai limiti di cui al documentazione per ciascuna delle tabelle e connessioni elencate sopra, è utile sapere che il numero massimo di risultati che otterremo prima di eseguire i controlli di visibilità è 5.000.

Riferimento: Paging with graph api and fql

Inoltre, v'è un limite non di risultati per una tabella. È possibile ottenere un dettaglio su di essi nelle rispettive tabelle fql.

Per tabella flusso (quello per messaggi/avanzamento),

Ogni query della tabella stream è limitata alle precedenti 30 giorni o 50 posti, il maggiore, tuttavia è possibile utilizzare tempo- specifici campi come created_time insieme agli operatori FQL (come < o>) per recuperare una gamma molto più ampia di post.

Riferimento: Fql stream table

Guardate anche qui: Facebook FQL stream limit?

+0

Grazie per la risposta. Ho già visto [la domanda che hai chiesto] (http://goo.gl/P9kpP). Ovviamente, il limite è limitato, ma questo è strano non possiamo trovare alcun dettaglio nel [doc] (http://bit.ly/f5O0Oz). Personalmente non posso ottenere più di 389 post e questo con un limite di 200 (vedi modifica). Quindi, direi che non puoi ottenere più di 400 post, non 500. Il 4 è più sulla paginazione: perché un limite di 10 rende la query recuperando meno post di un limite di 100? Ciò dovrebbe influire solo sul numero di pagine della paginazione, non sul numero di post. – sp00m

+0

Ho aggiornato il codice, spero che ti aiuterà :) – Jashwant

+0

Grazie. Te lo meriti :) – sp00m

0

Ci potrebbe essere un po 'di logica sul lato facebook per prevenire il data mining. Prova ad aggiungere un po 'di ritardo mentre scorri le pagine e vedi se è meglio.

3

C'è un bug in corso nel paging API grafico aperto di Facebook che ha a che fare con il parametro limite. Più alto è il limite, più pagine di post --- come se un limite inferiore elimini anche un campionamento di post. Il problema è emerso e si è ritirato da quando la funzione di ricerca post è stata interrotta per un mese a settembre.

Un nuovo bug è emerso: al momento una ricerca post senza un token di accesso e un piccolo limite (come 12) restituirà poche pagine di risultati scarsamente popolate. La stessa ricerca effettuata con il token di accesso fornito nell'esempio di documentazione API fornirà pagine complete di 12 risultati +/- e nessun salto. Non ho idea del tipo di access_token che usano, ma nessun tentativo da parte mia ha duplicato i risultati. La ricerca post senza token di accesso è più o meno non funzionale (di nuovo)!

Problemi correlati