Support per-query cache policies for file-based analytics queries
I maintainer di solito rispondono entro 3 giorni
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 45/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- sql, typescript
- Ambito
- backend-api-design, data
Direzione di ricerca
Inizia tracciando il punto di ingresso useAnalyticsQuery e la configurazione del plugin analytics, quindi esamina come vengono memorizzate nella cache le query basate su file nei percorsi di esecuzione JSON e Arrow. Definisci come le policy disabilitate o TTL per query preservino i valori predefiniti esistenti e l’isolamento dell’esecuzione, e verifica che le query disabilitate vengano rieseguite senza parametri nonce.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
AppKit's analytics plugin caches identical file-based SQL queries for one hour by default. Some queries are intentionally non-deterministic or calculate against current data and must execute every time the user submits them.
In AppKit 0.65.0, useAnalyticsQuery supports:
formatmaxParametersSizeautoStart
There is no per-query cache option. Caching can be disabled globally with:
createApp({
cache: {
enabled: false,
},
});
However, this disables caching for every AppKit plugin and analytics query in the application.
Example
-- config/queries/fresh_value.sql
SELECT current_timestamp() AS calculated_at
const { data } = useAnalyticsQuery('fresh_value');
After unmounting and remounting the component, the same cached timestamp is returned for up to an hour instead of executing the SQL again.
A more significant use case is a parameterized, non-deterministic table-valued function:
SELECT result_json
FROM IDENTIFIER(:functionName)(
:input,
:assumption
)
Submitting the same parameters again should deliberately recalculate against current source data.
Current workaround
We add a unique nonce to every submission:
-- @param queryNonce STRING
SELECT ...
WHERE length(:queryNonce) > 0
const [queryNonce] = useState(() => crypto.randomUUID());
const parameters = useMemo(
() => ({
input: sql.string(input),
queryNonce: sql.string(queryNonce),
}),
[input, queryNonce]
);
This works because parameters are part of the cache key, but it pollutes the SQL contract and creates cache entries that can never be reused.
Requested capability
Please support a server-controlled cache policy for individual file-based queries.
For example, a query directive:
-- @cache disabled
SELECT ...
Or configurable TTL:
-- @cache ttl=60
SELECT ...
Alternatively, plugin configuration could define the policy:
analytics({
queries: {
fresh_value: {
cache: false,
},
summary: {
cache: { ttl: 60 },
},
},
});
A client-side option such as the following would also be useful, although a server-owned policy would prevent clients from bypassing caching for arbitrary expensive queries:
useAnalyticsQuery('fresh_value', parameters, {
cache: 'no-store',
});
Expected behavior
- Existing queries remain cached by default.
- An individual query can disable caching or select a custom TTL.
- The policy applies consistently to JSON and Arrow execution paths.
- Service-principal and on-behalf-of-user execution retain their existing cache isolation.
- Disabled queries execute against the warehouse on every request without requiring dummy parameters.
- Lingua principale
- TypeScript
- Stelle
- 119
- Fork
- 36
- Merge medio
- 4g 16h
- PR unite (30g)
- 37
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di databricks/appkit
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
databricks/appkit#729 ·
I maintainer di solito rispondono entro 3 giorni
-
@databricks/lakebase: pool drops maxLifetimeSeconds and other pg options, so connections never recycle and Unity Catalog claims access fails after 4 hoursForse già presa @billmcmillin l’ha presa 5 giorni fa. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 20/100
databricks/appkit#718 ·
I maintainer di solito rispondono entro 3 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
databricks/appkit#699 ·
I maintainer di solito rispondono entro 3 giorni
-
Difficoltà 3/5 Mezza giornata Idoneità per principianti 42/100
databricks/appkit#656 · 1 commento ·
I maintainer di solito rispondono entro 3 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 28/100
databricks/appkit#648 · 2 commenti ·
I maintainer di solito rispondono entro 3 giorni
Tutte le issue di databricks/appkit
Issue simili
-
Add "append" and "prepend" slots for vue-vuetify extended renderersForse già presa @simeyc l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
eclipsesource/jsonforms#2668 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
README の通知条件を実際の判定処理に合わせるForse già presa @unhappychoice l’ha presa oggi. Apertafactory:in-progress priority:medium
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
unhappychoice/oss-issue-opener#395 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
bug Website
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
OWASP/OWASP-Hunting#88 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno