Open GoogleCodeExporter opened 9 years ago
I also would like to have this feature. It's at least vaguely similar to
NUnit's
ability to group tests by category. I would like to have several migrations
form my
"Core" module, and then have a "Test Data" module and a "Production Data"
module,
both of which would depend on the core module. The "Test Data" module would
consist
of made-up values for the purposes of testing, and "Production Data" would
consist of
real values imported from a database from another application.
Original comment by rawdatad...@gmail.com
on 20 Oct 2008 at 4:39
Since I currently need this feature, I'm going to start trying to implement it.
I'll
attach a patch when I've made enough progress (and this time I'll try to
remember to
include unit tests). At the moment, I don't need the ability to include
migrations
from multiple assemblies, so my work will focus on identifying modules by a
unique
string, all within a single assembly.
Original comment by rawdatad...@gmail.com
on 22 Oct 2008 at 6:45
Any progress on this? We're exploring a similar vain and would like to avoid
duplication.
Original comment by james.sa...@gmail.com
on 8 Mar 2009 at 9:28
echo the progress statement. I really need this functionality. We have multiple
services / modules that are developed standalone but use the same database and
would
like it version the database/ migration by schema name.
Original comment by l...@agilecoach.co.uk
on 26 May 2009 at 3:49
We ended up doing our own internal migration framework :)
Original comment by olivier....@gmail.com
on 26 May 2009 at 4:03
This source has been modified to support different modules. Each module has to
have
it's own migrator.
var migrator = new Migrator.Migrator("SqlServer",
ConnectionString,
"Persons",
typeof (AddPersonTable).Assembly);
I tried to modify as little as possible in the original code to make this work.
This
will not work with existing versions of migrator.net since I had to modify the
schemaInfo table. All your migrations will still work but if you want it to be
modularized then you will have to declare a moduleName on your attributes.
ex. [Migration(version:1, ModuleName="Persons")]
If you leave out the ModuleName then it will default to "DEFAULT".
I also updated the MigrateTasks to use the new ModuleName.
Well have fun using this.
This is the source, so get the latest source code and replace the src folder
with
this src folder and rebuild.
Original comment by birdch...@gmail.com
on 16 Feb 2010 at 2:16
Attachments:
man it would great if this was added to the actual migrator.net releases
Original comment by da...@sabrecreations.com
on 14 Aug 2013 at 11:56
Original issue reported on code.google.com by
olivier....@gmail.com
on 6 Oct 2008 at 1:22