No Support for the MigrateDatabaseToLatestVersion database initializer?

Apr 25, 2013 at 10:24 PM
Currently I am using the MigrateDatabaseToLatestVersion database initializer. Any plans on supporting that? Support for those people who don't want to throw away the database. Also, we use Migrations so that we can execute T-SQL during the migration within the Seed method. Here is an example:
protected override void Seed(CustomContext context)
        {
            //  This method will be called after migrating to the latest version.

            // Add any database objects "external" scripts, meaning not generated from EF here.
            string pathSQLScripts = ConfigurationManager.AppSettings["ExternalMigrationsCustomerSQLScriptsPath"];
            string sqlConnectionString = ConfigurationManager.ConnectionStrings[ConfigurationManager.AppSettings["DefaultCustomConnectionString"]].ConnectionString;
            DirectoryInfo diSQLScripts = new DirectoryInfo(pathSQLScripts);
            FileInfo[] filesSQLScripts = diSQLScripts.GetFiles("*.sql");

            // Process each SQL script.
            foreach (FileInfo fi in filesSQLScripts)
            {
                FileInfo fileInfo = new FileInfo(fi.FullName);
                string script = fileInfo.OpenText().ReadToEnd();
                SqlConnection connection = new SqlConnection(sqlConnectionString);
                Server server = new Server(new ServerConnection(connection));
                server.ConnectionContext.ExecuteNonQuery(script);
            }
}
If you change your Package to not use DbSet from within the XML, and make it to where we can call your functionality from within the Seed method, then I would think we could possibly use it as part of Migrations as well as the other database initializers. The other database initializers allow us to use the Seed method. Right? I just feel that if you don't support MigrateDatabaseToLatestVersion when Database.SetInitializer() is called, then I can think of no other way to use this package in our case. Thoughts? Althought your package is very attractive to me, I just don't want to abandon the Migrations concept that EF has introduced, just for the sake of seeding functionality that you provide.
Coordinator
May 3, 2013 at 1:36 AM
Sorry for the slow reply. Apparently I was not subscribed to "all discussions", so I wasn't getting notifications. I just fixed that. Yeah, I've been dragging my feet on supporting MigrateDatabaseToLatestVersion. I'm going to be making some improvements over the next few days. I'll definitely make it a priority. I briefly looked it previously. EF's MigrateDatabaseToLatestVersion has no Seed method to override like the other IDatabaseInitializer implementations. So, I'll need a new strategy.

However, it may be possible to do what you need with the package as-is. Although I haven't documented it, you can use the seeder functionality without using one of my database initializers. You will need an instance of your DbContext though.
var seeder = new CodeFirstSeeder.Xml.Seeder<TContext>(contextInstance, xmlFilePath) ; //xmlFilePath is optional just like for the db initializers
seeder.Seed();
Also, if you are using V1.0.3 (code is on Github, package is on Nuget), another poorly documented feature is the ability to store T-SQL in the seeder's xml file to execute before or after seeding. See https://github.com/ebrenttaylor/code-first-seeder/wiki/SQL-Commands. Note this version only works with EF 5.0. (A main item on my todo list is make new versions backwards compatible with EF 4.x).

Anyway, I'm glad you've found it somewhat useful. Although, I've been falling behind, more development is on the way very soon.