NHibernate and Database Changes and Deployments

I am studying the use of NHibernate and Fluent NHibernate for my next project, but I would like to clean myself up, how do you manage database changes?

for example, NH + FNH works for me, the application has been deployed and is available, but we are making changes to the development environment, for example, we add a new property to an entity that maps to using NH / FNH.

How do you apply this change to the database without dropping the table?

Thanks. GE

+3
source share
6 answers

I have very good experience using this structure:

http://code.google.com/p/migratordotnet/

Basically, you create a class for each database change and annotate the class with a timestamp. The final assembly is then applied in order of time stamp.

This means that during development, after each check, it becomes easier to just blindly start the db update process and know that you are in sync with the world.

using Migrator.Framework; using System.Data; namespace DBMigration { [Migration(20080401110402)] public class CreateUserTable_001 : Migration { public void Up() { Database.CreateTable("User", new Column("UserId", DbType.Int32, ColumnProperties.PrimaryKeyWithIdentity), new Column("Username", DbType.AnsiString, 25) ); } public void Down() { Database.RemoveTable("User"); } } 
+9
source

AFAIK, you need to do this manually. You can export your schema to each initialization, but you cannot automatically modify your tables. Because the schema will only contain create statements.

Perhaps you can use a tool like Red Gate to find differences in the database and could automatically create instructions for you. The idea is this:

-Detailed the circuit in the test database
- Run the Red Gate tool and find the DIFF at the circuit level.
-Create a diff script automatically
-Click diff on your main db

+4
source

NHibernate supports the SchemaUpdate class, which can create some modifications to the scheme, but not all. More information here:

How to update database table schemas using NHibernate schema generation?

+4
source

No matter which ORM tool you use, if you make schema changes, you will have to deploy the code and schema changes at the same time. For our project, this means that for each version containing schema changes, we write a sql script that is used to update the database. This script is executed by our installer at the same time that the code containing the new hibernation mappings is deployed to the server, and the new application does not start until the circuit modifications are completed.

Using this method, we were able to modify tables, drop tables, add tables, and transfer data from one table to another without any major problems. Having a script to perform database changes allows you to thoroughly test it before deploying it to production.

+2
source

This is the process that I developed. I think it is quite smooth.

A process is something like this, assuming you have a db called 'MyDb'

  • Make your changes to your NH model and display
  • Run the script to then create a db named MyDb_Next and execute NH SchemaExport to write the new schema.
  • Use my MigrationScriptGenerator tool to compare MyDb and MyDb_next. This will generate your change scripts (or as many of them as possible) by comparing the schema and creating statements to add new columns, etc. script will be saved to xxxx file - updatescript.sql.sposed in VS project
  • If necessary, correct the proposed sql script (it requires human input when it detects changes that may lose data) and rename it to .sql (so that it can be selected in the next step)
  • The post build event in a project containing sql scripts fires my simplescriptrunner tool, this applies to the sql script for MyDb, updating it

You simply repeat this process when you change your entities. I usually store my SQL scripts inside .csproj and have a post build event that fires simplescriptrunner. Thus, any other developer who performs the upgrade and rebuild will have the latest version of db generated on his computer from the ones tested in numbered scripts.

MigrationScriptGenerator uses OpenDBDiff (an open source tool similar to Red SQL SQL Compare) to create a script. You may find this useful if you want to create scripts yourself.

PS these tools only work with SQL Server - sorry!

+1
source

I know this is an old question, but I came across it as the best result on google and does not mention a tool that seems to be the standard for NHibernate migration - Fluent Migrator

+1
source

All Articles