Hi, looks good. I've been using FluentMigrator to do my migrations. The migration version history is stored in the database (in a single table). I use a modular approach to my application where each module has a separate version history. Therefore I made changes to allow the assembly name to be stored inside the migrations table aswell.
On Wednesday, 24 September 2014 16:26:25 UTC+1, Jeffrey Becker wrote: > > I've got my migrations stuff > <https://github.com/jeffreyabecker/nhibernate-core> to the point where > I'm comfortable declaring it "alpha". It's usable but the tooling isn't > there. Please kick some tires and let me know what questions you have so I > can start getting blog posts written. > > A demo application is available at > https://github.com/jeffreyabecker/NHMigrationDemo. > A quick-summary is available at > https://weblogs.asp.net/jeffreyabecker/nhibernate-migrations-proposal-part-1-configuration > . > > I've got a couple of architecture questions which I'd like feedback on: > > > The default strategy is to store migration history in a mapped entity. > Right now this strategy is in the main NHibernate assembly. Should this > be moved into a separate assembly/nuget package or are people ok with it > living where it is now? > Is VB.Net support a major need? > Should the generator attempt to generate migrations using the Fluent dsl > or just target the underlying IDdlOperation framework? > > > > -- --- You received this message because you are subscribed to the Google Groups "nhibernate-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
