2013-01-09 8 views
5

Ad esempio, è necessario utilizzare key_prefix?Cosa fa `key_prefix` per flask-cache?

@cache.cached(timeout=50, key_prefix='all_comments') 
def get_all_comments(): 
    comments = do_serious_dbio() 
    return [x.author for x in comments] 

cached_comments = get_all_comments() 

Nel document, si dice che il valore di default 's il key_prefix è request.path cache_key.:, quello che fa cache_key media, come posso usarlo? Cosa fa key_prefix?

risposta

12

Prima il request.path è tutto (tranne i parametri) dopo il script_root. Per esempio:

  1. per un URL simile, http://127.0.0.1:5000/users/login/, richiesta di dati è:

    request.path is: /users/login/ 
    
  2. per un URL come nell'esempio dal link qui sopra, http://www.example.com/myapplication/page.html?x=y, richiesta di dati è:

    request.path is: /page.html 
    

D. Che cosa significa cache_key, come posso usarlo?

Il cache_key è la chiave utilizzata per accedere al particolare valore memorizzato nella cache. Come sapete, la cache è un negozio con valore-chiave.

In Flask-Cache lo viene generato dall'estensione e non è previsto che lo usiamo noi stessi.


D. Che cosa significa key_prefix fare?

key_prefix viene utilizzato per generare il valore cache_key per un valore memorizzato nella cache. Vedi make_cache_key source per vedere come è fatto esattamente.


D. E 'necessario usare key_prefix?

Diciamo che si sta chiamando get_all_comments da 2 diverse funzioni di visualizzazione, dicono manage() e view(). E non si specifica un key_prefix, mentre la cache get_all_comments con @cached.

La prima volta che visualizzare un post attraverso view l'uscita get_all_comments viene memorizzato nella cache con un default key come: view/view o view/module/view, o qualunque sia il valore di view/%s è, dove è %srequest.path.

successivo quando si gestire un post attraverso manage, l'uscita get_all_comments non viene letto dalla cache, dal momento che la cache_key applicato per ottenere i dati dalla cache è cambiato per view/manage e non è il vecchio view/view, perché la richiesta. il percorso è ora cambiato.

L'intero punto della cache get_all_comments qui era quello di ottenere i dati dalla cache ogni volta che è possibile e non il db, ma poiché le chiavi sono cambiate tra le funzioni di visualizzazione i dati vengono effettivamente recuperati entrambi i tempi dal db stesso.

Tuttavia nel caso in cui si era specificato un key_prefix come all_comments, quindi i primi dati volta viene recuperata dal db, e la prossima volta il cache_key è ancora all_comments e si trova il valore, ed i dati si accede dalla cache invece di db .

Quindi, quando si dispone di casi come sopra, è ovviamente meglio usare uno key_prefix, in altri casi quando la funzione viene sempre chiamata da una singola funzione percorso/vista, allora è ok lasciare che venga utilizzata quella predefinita.


Nota: Viene generato il cache_key/calcolati per ogni richiesta, vedere la source: bella risposta

cache_key = decorated_function.make_cache_key(*args, **kwargs) 
+2

! Volevo solo aggiungere, che prefix_key può anche essere un callable il cui valore di ritorno sarà usato come cache_key. Quindi immagino possa essere "abusato" per passare la propria funzione make_cache_key. Vedi il mio esempio qui http://stackoverflow.com/questions/9413566/flask-cache-memoize-url-query-string-parameters-as-well/14264116#14264116 – Smoe

+0

@Smoe hai assolutamente ragione, ['se callable (key_prefix): cache_key = key_prefix() '] (https://github.com/thadeusb/flask-cache/blob/master/flask_cache/__init__.py#L218) –