Migrazioni dati
Esegue una singola migrazione dati scritta in Go, indicata per nome, inclusa in una release.
Come funziona
Alcune modifiche non si possono esprimere in SQL: riscrivere i payload degli eventi in un nuovo formato binario, normalizzare dati legacy, ricalcolare campi derivati. Ognuna di queste modifiche viene rilasciata come migrazione scritta in codice — un’attività — nell’applicazione.
Si esegue un’attività alla volta, indicandola per nome. Non esiste deliberatamente una modalità “esegui tutto”: passare in rassegna tutte le migrazioni in un colpo solo è senza limiti e attraversa ogni workspace, e in precedenza bastava lasciare vuoto un campo per farlo. Il campo Task è obbligatorio e il suo elenco mostra esattamente le attività registrate dalla versione distribuita.
Un’esecuzione procede poi così:
- Anteprima per impostazione predefinita — con Apply disattivato l’attività riporta ciò che modificherebbe, senza scrivere nulla. Leggi prima l’anteprima: è esattamente a questo che serve
- Scrive solo su tua indicazione — attiva Apply per confermare. Il modulo richiede una conferma esplicita, perché le modifiche vengono scritte in ogni workspace interessato e non possono essere annullate
- Ricostruisce eventualmente le proiezioni — un’attività che modifica i payload degli eventi in un modo che le proiezioni devono riosservare lo dichiara come attività successiva. Al termine dell’esecuzione il worker pianifica Ricostruzione proiezioni dipendenti come nuova esecuzione. L’esecuzione concatenata compare nell’interfaccia di amministrazione come voce distinta, avviata rigorosamente dopo il completamento dell’esecuzione di migrazione
Quando viene eseguito
Il job è guidato dall’operatore. È registrato presso il worker ma non si attiva mai da solo — l’API non lo esegue all’avvio. Attivalo quando serve una migrazione, da . Può essere eseguito solo dall’area di lavoro di sistema e non compare in nessun’altra area di lavoro.
L’attivazione automatica è stata disabilitata perché repliche API in scalabilità automatica accoderebbero ciascuna un’esecuzione duplicata, e esecuzioni concorrenti sulle stesse righe producono contesa sul database e un’ondata di eventi di replay.
Parametri
| Parametro | Obbligatorio | Significato |
|---|---|---|
| Task | Sì | La migrazione da eseguire, scelta tra le attività registrate. Un’esecuzione che non indica alcuna attività viene rifiutata prima che inizi qualsiasi lavoro, così come un nome non registrato |
| Apply | No | Disattivato (predefinito) mostra l’anteprima senza scrivere, per le attività che lo supportano; le attività che scrivono sempre lo ignorano. Attivato conferma le modifiche, che non possono essere annullate |
| Employee | No | Restringe un’attività circoscritta a un singolo dipendente — utile per provare su un dipendente prima di un’esecuzione globale. Le attività che operano sempre globalmente lo ignorano |
L’API programmatica accetta le stesse opzioni, più workspace_id per restringere un’attività circoscritta a un workspace; nel modulo non è previsto un selettore di workspace.
{"jobs":["migrations"],"options":{"tasks":["<nome-attività>"]}}
{"jobs":["migrations"],"options":{"tasks":["<nome-attività>"],"apply":true}}Le opzioni ricevute da un’esecuzione sono visibili nella colonna Parametri dell’elenco delle esecuzioni, nascosta per impostazione predefinita: attivala dal menu delle colonne per distinguere due esecuzioni dello stesso job.
Risultati del job
Il risultato riporta dry_run (l’opposto di Apply) e una chiave per ogni attività eseguita:
| Chiave | Significato |
|---|---|
dry_run | true quando non è stato scritto nulla — l’esecuzione ha solo mostrato un’anteprima |
applied | Indica se l’attività ha effettivamente scritto le proprie modifiche |
affected_count | Quante entità l’attività ha toccato, o toccherebbe |
by_workspace | I conteggi per workspace, con i nomi risolti |
details | Le entità interessate, con i dettagli prima/dopo registrati dall’attività |
Un nome che non corrisponde a un’attività registrata compare come "unknown task" accanto a quel nome.
Quando viene eseguita un’attività contrassegnata come “ricostruisce le proiezioni”, il risultato include anche next_jobs: ["rebuild-employee-projections"] e il worker pianifica automaticamente quel job.
Riesecuzione
Tutte le attività registrate sono rieseguibili su richiesta. La query di selezione di ciascuna attività esclude le righe già migrate: una riesecuzione dopo un successo parziale riprende da dove si era interrotta, e rieseguire un’attività completata non fa nulla e riporta zero entità interessate.
Risoluzione dei problemi
| Problema | Soluzione |
|---|---|
| “No task selected” | Scegli un’attività nel campo Task. Non esiste una modalità “esegui tutto”: indicare l’attività è l’unico modo per eseguire questo job |
L’esecuzione riporta "unknown task" | Il nome non è registrato nella versione distribuita — di solito un’attività nel frattempo ritirata. Scegli dall’elenco invece di digitare un nome |
| Run Job resta disattivato | Apply è attivo e la conferma sottostante non è spuntata. Leggi l’avviso e spunta la casella, oppure disattiva Apply per limitarti all’anteprima |
affected_count è 0 | L’attività non ha righe in sospeso — la condizione normale una volta completata |
| Errori durante un’attività | Apri i dettagli dell’esecuzione. Gli errori per riga sono riportati; il fallimento dell’intera esecuzione indica di solito una condizione fatale. Correggi i dati ed esegui di nuovo |
| La ricostruzione delle proiezioni non è partita | Se l’esecuzione non ha raggiunto lo stato “completed” (fallita a metà), l’attività successiva viene saltata. Correggi l’errore, riesegui l’attività, poi esegui manualmente Ricostruzione proiezioni dipendenti se necessario |