Migration runs, but database not affected

[Rémi]

I must be missing something pretty basic.

I'm working on a legacy project, and I'm trying to bring
FluentMigrator into the mix cause I've got some interesting database
changes and data migrations coming up that I think will be made much
easier by using this tool.

For the initial migration, I just want to bring the database up to the
current production version, as-is. To simplify the initial migration,
I scripted out my SQL Server 2008 database, and the migration executes
the scripted commands as a series of SQL commands.

To test it out, I create an entirely empty database, and try to run it
from command line using this:

> migrate -a "C:\My\Project\Path\bin\debug\Rds.LoanExpress.DBMigrations.dll" -db SqlServer2008 -conn "Data Source=.\SQLEXPRESS2008;Initial Catalog=myNewDbName;Integrated Security=SSPI" -version=20100901000000

The version specified is the timestamp on the first migration class's
Migration attribute.

At the command line, everything appears to run fine - the the entire
script zooms by, and it ends with:

-- CreateProducxtionDbCircaSep2010: migrated

However, when I take a look at the database, it is still empty.
Absolutely nothing is in there. My Up method looks like this:

public override void Up()
{
var cmds = LoadEmbeddedResources
.GetEmbeddedResource("scripted_db_2010-09-01.sql")
.AsString()
.ParseCommands();

foreach (var c in cmds) {
Execute.Sql(c);
}

CreateReferenceData();
}

(FYI, I'm parsing the script instead of running it as-is because I
started by using Migrator.Net before discovering it was dead, and this
was already set up.)

Can anyone give me a hand? It almost appears like a transaction isn't
committing, or some command-line option to have the migration do a dry-
run is turned on, but I don't see it...

Thanks.

[Sean Chambers]

First, I'm not using Execute.Sql() anywhere. We usually do Execute.SqlScript("whatever.sql");, so I can't speak to Execute.Sql().

Can you post the output from the execution? This would help debug further, as if it's running in preview only mode it would state so.

What may have happened, is when transaction support was added to migrations, we may have missed the Execute.Sql portion, but this is unlikely because the transaction is scoped at the migration run and not down to that level. Everything looks ok with what your're doing however.

Sean

--
You received this message because you are subscribed to the Google Groups "FluentMigrator Google Group" group.
To post to this group, send email to fluentmigrato...@googlegroups.com.
To unsubscribe from this group, send email to fluentmigrator-goog...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fluentmigrator-google-group?hl=en.

[Rémi]

It doesn't look like it makes a difference. I tried running it using
Execute.Script, and it succeeded - but I still don't see any
difference in the DB. To make sure my connection string was hitting
the correct database, I renamed it - and got a login error when I
tried the migration, as the database wasn't found, as expected.

Am *I* supposed to be committing the transaction somewhere?

I cut down the script length for a few tests... Here's the output on
my last test, when I ran I executed the entire small script using

Execute.Script(@"..\Resources\test.sql");

as opposed to what I noted above. Even the VersionInfo doesn't exist
at the end of the run. Output:


C:\My\Project\Path\FluentMigrator.Net\ >migrate -a "C:\My\Project\Path
\bin\debug\My.Project.DBMigrations.dll" -db SqlServer2008 -conn "Data

Source=.\SQLEXPRESS2008;Initial Catalog=myNewDbName;Integrated
Security=SSPI" -version=20100901000000

Using Database SqlServer2008 and Connection String Data Source=.

\SQLEXPRESS2008;
Initial Catalog=myNewDbName;Integrated Security=SSPI

-- VersionMigration: migrating
===============================================

-- CreateTable VersionInfo
-- VersionMigration: migrated
-- CreateProductionDbCircaSep2010: migrating
=================================

-- ExecuteSqlScript C:\My\Project\Path\FluentMigrator.Net\..\Resources
\test.sql
-- CreateProductionDbCircaSep2010: migrated

[Sean Chambers]

Yeah. This is definitely something wrong with the transaction
management.

There is nothing you need to do woththe transactions. They are started
and committed for you.

What version are you using? It might be worthwhile to grab the latest
assemblies from teamcity.codebetter.com and see if that makes a
difference. Other than that we can look at it if you log an issue in
github.

Or if you need a fix sooner, you can attempt to patch it and send us a
pull request. The problem must be somehwhere around MigrationRunner as
this is where transaction management is handled.

Sean

[Rémi]

I grabbed the source from teamcity.codebetter.com, and it looks like
I'm getting the same results.

I'm going to look at it a bit (cause I need something like this for my
current work), but I admit I'm behind on a release already so I'm not
sure how much time I'll spend before putting it aside.

If I do get to the bottom of it, I wouldn't be against submitting a
patch, but I'm not sure of the steps to get there - I haven't
submitted patches to open-source projects before, nor worked with
github.

Regardless, I'll reply to this thread if I find anything.

Remi.

On Nov 16, 4:06 pm, Sean Chambers <schamber...@gmail.com> wrote:
> Yeah. This is definitely something wrong with the transaction  
> management.
>
> There is nothing you need to do woththe transactions. They are started  
> and committed for you.
>
> What version are you using? It might be worthwhile to grab the latest  
> assemblies from teamcity.codebetter.com and see if that makes a  
> difference. Other than that we can look at it if you log an issue in  
> github.
>
> Or if you need a fix sooner, you can attempt to patch it and send us a  
> pull request. The problem must be somehwhere around MigrationRunner as  
> this is where transaction management is handled.
>
> Sean
>

[Rémi]

FYI, looks to me like the problem comes up when running the tool with
a version specified...

The TaskExecutor class's Execute method will call
Runner.MigrateUp(RunnerContext.Version) or Runner.MigrateUp(),
depending on whether or not a version number has been specified;
Processor.CommitTransaction() is only called in the latter method,
commit is never called if you've specified a specific version for your
migration.

I've been specifying my version explicitly, to test my migrations one
at a time, so no commit.

If you don't mind helping me out a bit, I can try and get a patch
together. Otherwise, I'll leave it to you guys and whatever you wish
to do with it.

Best,
Remi.

[Sean Chambers]

Excellent. Glad you found it.

First thing I would look at is if there is a test wrapped around that
method abd if not, create a test to produce a failure so that you can
verify that the issue has been fixed.

Second, refactor that method to both start a transaction and that
could get your test passing. If you need additional/different guidance
let me know and we can go from there.

Thanks!

Sean