Mettre à jour le schéma de la base de données de production avec NHibernate et ajouter des données par défaut

Question

Je cherche des idées sur la façon dont les autres gèrent la situation suivante - J'ai quelques idées mais elles semblent un peu brouillon et je ne peux m'empêcher de penser Il me manque quelque chose.

est ici la situation:

• Vous utilisez NHibernate avec Fluent NHibernate pour les correspondances.
• Vous avez une application en production avec une base de données avec des données en direct
• Vous ajoutez une nouvelle fonctionnalité en développement et une nouvelle colonne de base de données est requise.

La nouvelle colonne ne peut pas être vide. Par exemple, j'ai récemment eu une colonne DateCreated à une table et l'application utilise maintenant cette date. Comme la seule fois où les données seront manquantes est maintenant, il semble inutile d'ajouter du code pour vérifier les erreurs.

Dans mon application, j'ai un programme de mise à jour qui peut exécuter un SchemaUpdate pour ajouter la nouvelle colonne de base de données - cependant, l'application va se bloquer car elle attend une valeur dans la nouvelle colonne.

J'ai besoin d'obtenir des données par défaut sensibles dans cette colonne. Dans ce cas, j'ai manuellement exécuté une mise à jour pour définir la date à la date actuelle (assez bon pour la situation). Dans ce cas particulier, je crois que vous ne pouvez pas définir la valeur par défaut de la colonne getdate() en utilisant des mappages fluides.

Mon idée

• Gardez un numéro de version de schéma dans un fichier de configuration
• Dans Updater qui va SchemaUpdate commencer à ajouter des méthodes de mise à niveau pour chaque version. Ces méthodes exécuteraient des mises à jour pour ajouter des données par défaut (ou d'autres actions requises).
• Une fois la mise à jour du schéma exécutée, appelez toutes les méthodes requises pour une version supérieure à la version actuelle (c'est-à-dire celles qui n'ont pas été précédemment exécutées). Donc, si l'application est maintenant la version 4 et la version 2 est installée, les méthodes 3 et 4 seraient exécutées.
• Mettre à jour le numéro de version enregistrée

Comment sont les autres personnes qui manipulent cette situation?

Answer 1

utilisation DBDeploy (http://dbdeploy.com/)

La façon dont cela fonctionne est:

• Créer un groupe de scripts alter numérotés en série pour créer votre schéma
• Dites à DBDeploy crée le script à appliquer.
• DBDeploy examinera vos scripts alter et la base de données pour appliquer les scripts et créer un script consolidé pouvant être exécuté sur la base de données de production.
• DBDeploy gère une liste de scripts appliqués dans le DB de production.

Jetez aussi un coup d'œil à http://goforthandcode.blogspot.com/2007/12/brief-history-of-database.html si vous avez besoin d'un peu d'une explication des scripts alter

Divulgation: Je travaille pour ThoughtWorks et certains de mes collègues ont créé DBDeploy et DBDeploy.Net

Answer 2

Pour résoudre problèmes de versionnement de base de données il y a beaucoup de différents cadres. J'utilise MigratorDotNet. Il est open source et fournit une API très simple. MigratorDotNet fait la même chose que vous voulez, mais stocke la version de base de données dans une table spéciale qui sera créée lors de la première exécution.

De plus, il est créé en tant qu'application console et c'est pourquoi vous pouvez l'utiliser très facilement sur votre serveur CI.

Answer 3

Utilisez SchemaUpdate, une fonctionnalité de nHibernate. Pour les données de référence, j'utilise un code d'importation simple à partir de données formatées standard (telles que CSV). Lorsque l'application est mise à jour, de nouvelles données sont importées à partir de ces fichiers. La logique met à jour les données uniquement si elles ont été modifiées ou sont nouvelles. Pour cela, j'ai une colonne supplémentaire qui est ModificationDate.

Je conserve de nouvelles données de référence dans un fichier compressé avec une autre extension pour éviter toute confusion (.dat).

Cela fonctionne très bien, et je l'ai utilisé dans de petites applications de bureau et de grands projets d'entreprise. La version de la base de données est stockée dans la base de données dans une table appelée DatabaseSetting.