Prima il request.path
è tutto (tranne i parametri) dopo il script_root
. Per esempio:
per un URL simile, http://127.0.0.1:5000/users/login/
, richiesta di dati è:
request.path is: /users/login/
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 è %s
request.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)
! 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
@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) –