manutenzione / migrazione dei dati in sistemi basati su immagini

Question

manutenzione / migrazione dei dati in sistemi basati su immagini

#1 da (1 voti)
#2 da (1 voti)

4

Le applicazioni Web di solito hanno un database. Il codice e il database lavorano insieme insieme. Pertanto quadri come Ruby on Rails e Django crea file di migrazione

Sicuramente ci sono anche server scritti in Self o Smalltalk o altri sistemi basati su immagini che affrontano lo stesso problema: il codice non è scritto sul server ma in un'immagine separata del programmatore.

In che modo questi sistemi gestiscono uno schema che cambia, cambiando classi / prototipi. In che modo vengono effettuate le migrazioni?

Esempio: qual è il processo di un nuovo attributo che va dall'idea del programmatore al codice del server e tutti gli oggetti?

Ho trovato il manuale Gemstone / S capitolo 8 ma in realtà non parla del processo di spedizione del codice sul server.

maintenance migration smalltalk image

posta User 21.06.2013 - 18:13

fonte

2 risposte

Leggi altre domande sui tag maintenance migration smalltalk image

Mixing Fowlers Transaction Script e Domain Model "Definitivo" Schema REPL definizioni: come salvarle?

score 1 · Answer 1

Penso che il metodo basato sui file di migrazione sia stato un'innovazione.

Prima che i nuovi schemi venissero creati principalmente costruendo "convertitori", in altre parole, creando un'immagine completamente nuova, quindi copiando i dati utente nella nuova forma.

In alternativa un'immagine può contenere metadati della versione dello schema per record in modo che un lettore possa migrare (e memorizzare in un nuovo formato) al volo o in un processo in background (priorità bassa). Tecniche simili che potresti trovare costruite in cima ai database di documenti in questi giorni.

L'attenzione alla migrazione basata su piccoli testi in piccoli delta è stata comunque un miglioramento rispetto alle pratiche precedenti.

score 1 · Answer 2

In Gemstone ci sono versioni di classi e puoi avere oggetti di più versioni di classi nel sistema. Per impostazione predefinita, l'aggiunta di un nuovo attributo aggiunge semplicemente un valore nullo. Con una lazy accessor puoi semplicemente impostare il valore quando necessario. Oppure puoi eseguire una migrazione attiva e decidere cosa deve succedere, sia per tutti i vecchi oggetti quando si carica la nuova definizione di classe o pigramente, ogni volta che ne viene utilizzato uno.

In Pharo abbiamo solo il comportamento predefinito, aggiungendo una variabile di istanza su di esso. Ciò significa che il caricamento di una nuova versione può potenzialmente essere lento, ad es. quando è necessario aggiungere un instVar a un milione di oggetti. Se abbiamo bisogno di più di una nuova proprietà, aggiungiamo il codice di migrazione che viene eseguito prima o dopo aver caricato la nuova versione.