NHibernate SchemaUpdate è sicuro nel codice di produzione?

Question

Per semplicità. Sto utilizzando Automapping di Fluent NHibernate in combinazione con SchemaUpdate di NHibernate durante il runtime. Ad ogni esecuzione Automapper crea associazioni per tutte le classi di entità e SchemaUpdate applica lo schema al database esistente. Sono rimasto piacevolmente sorpreso dal fatto che funzioni correttamente anche su un database vuoto. Ha funzionato fino ad ora in un ambiente di sviluppo e mi ha permesso di rispondere agli errori piuttosto rapidamente.

La mia domanda è se è abbastanza affidabile da lasciare nel codice di produzione. Ovviamente non è necessario eseguire ogni volta che il programma viene avviato in un ambiente di produzione, ma sarebbe utile per gli aggiornamenti incrementali del prodotto (sebbene non preveda di apportare modifiche importanti al dominio dopo la spedizione del prodotto).

(Forse la mia vera domanda dovrebbe essere come è sicuro da usare questi due strumenti in combinazione?)

Aggiornamento

L'applicazione ha due versioni: un desktop stand-alone e client/server multiutente . Anche a causa della natura del dominio aziendale (software fiscale) ho il lusso di iniziare con un database pulito ogni anno.

Answer 1

Affinché questo sia in grado di essere eseguito nel codice di produzione, l'account che l'applicazione di produzione utilizza per connettersi al database dovrebbe disporre dell'autorizzazione per modificare lo schema del database.

Questo da solo dovrebbe scoraggiare da questo approccio, indipendentemente dalla qualità/affidabilità del codice NHibernate.

Answer 2

Dipende da quanto sono importanti i dati! Dubito che sia una buona idea per un sistema bancario. Non ho avuto alcun problema con l'aggiornamento a parte una cosa. A volte non rinomina correttamente. Inoltre è un rischio per la sicurezza connettersi con un account che può modificare lo schema :)

Answer 3

Si potrebbe voler considerare che SchemaUpdate apporterà sempre modifiche additive e non distruttive, con conseguente colonne stantia e colonne nullable dove dovrebbero essere non annullabile.

In altre parole, assolutamente non per uso produttivo.

Answer 4

Non vorrei rischiare. Ciò che funziona bene è eseguirlo su un server di staging che è stato ripristinato dalla produzione, quindi utilizzare uno strumento di confronto del database (come Red Gate) per esaminare le modifiche e generare uno script.