bretcope / mayflower.net Goto Github PK

There are two projects in Mayflower. One is a library (Mayflower) which provides all of the core functionality. The other is MayflowerCLI which generates the executable mayflower.exe. I'll address each one separately.

Mayflower (Library)

This project should be converted to target .NET Standard 1.3. I say 1.3 because that's the highest version implemented by both .NET Core 1.0 and .NET Framework 4.6. I don't think this will be difficult at all. The project has literally zero nuget dependencies currently, and it doesn't use any reflection or platform-specific features that I can think of. I'll give it a shot this weekend.

API

I'd like to take another look at the use cases for calling the library directly (as opposed to using the CLI) and reexamine what the API should look like. I wouldn't rule out the possibility of a major redesign before 1.0.

MayflowerCLI

I would actually like to work on compiling this with .NET Native. Right now I do an embedded resource trick to include the Mayflower.dll inside the exe, but the exe itself still requires .NET Framework 4.6 be installed on the machine. If we could compile a native exe, that would no longer be an issue.

I've only just started looking into how to use .NET Native, but since there's no JIT, my impression is that you can't emit IL at runtime. Last night, I got rid of the Dapper dependency in anticipation of that limitation.

It warrants more investigation. Hopefully it's not a big undertaking. If it is, we could revert back to the embedded resource approach for the time being. The code would be a little different in .NET Standard because AppDomains are gone, but I'm pretty sure it's still possible to dynamically load dll's from embedded resources.

Tests

We'll also need a third project for tests. NUnit's .NET Standard support was still in beta last I checked, but there are probably work arounds.

I have a local SQLServer instance named SQLSRV. I usually connect to it using the following connectionstring:
data source=.\SQLSRV;initial catalog=mayflowertests;persist security info=True;MultipleActiveResultSets=True;integrated security=SSPI

When I try to deploy migrations using mayflower I get a connection error, I've tried these commands but they result in errors:

1. mayflower -d .\migrations\ --connection "Server=(local)\SQLSRV;initial catalog=mayflowertests;persist security info=True;UID=sa;PWD=mypw;MultipleActiveResultSets=True"

2. mayflower -d .\migrations\ --connection "Server=.\SQLSRV;initial catalog=mayflowertests;persist security info=True;UID=sa;PWD=mypw;MultipleActiveResultSets=True"

3. mayflower -d .\migrations\ --connection "Server=.\\SQLSRV;initial catalog=mayflowertests;persist security info=True;UID=sa;PWD=mypw;MultipleActiveResultSets=True"

results in - message: 'Failed to lookup instance on (local) - getaddrinfo ENOTFOUND (local)'

does mayflower support local named instances?

Hi Bret,

Is this project maintained?

Thanks!

There should be a command where you can mark one or more migrations as having been run, even when they haven't explicitly been run by Mayflower. The principle use case for this is if you were using a different migrator in the past, but want to switch to Mayflower now. However, I imagine there are other use cases, especially for local development.

It would be nice to have the possibility to include a file in a migration.
Something like the command :r of sqlcmd (https://docs.microsoft.com/en-us/sql/tools/sqlcmd-utility?view=sql-server-2017)

Use case:
The procedures / functions / triggers / views are mantained in their own files. When such an object is released, a new migration is created that includes the file that contains the object.
Advantage: when I debug an issue and I want to see the changes for a procedure, it is easy to do so by using the history option of svn/github/hg.

Right now setup options are being conflated with command options. For example, "UseGlobalTransaction" is not relevant if you're only looking to get a count of outstanding migrations. It's specific to the command you're running. Whereas "MigrationsTable" is relevant to any command, so it's more of a setup option.

I'd like to rework Mayflower such that the Options object only contains setup properties. These are:

• ConnectionString
• Database
• Server
• Directory
• MigrationsTable
• Output
• AutoRunPrefixes
• Provider (not actually settable currently)
• Verbosity (planned feature)

The Output option is a bit ambiguous as to whether it's a setup or a command option. I'm leaning more towards setup, for simplicity.

Current properties which would be removed from the Options class:

• CommandTimeout
• IsPreview
• UseGlobalTransaction
• Force

The Migrator object would be refactored to allow it to be constructed directly using an Options argument, then you could run as many commands on it as you want. Each command would correspond to an instance method on Migrator, and would accept parameters as the command options, rather than having a dedicated Options class for each command.

Furthermore, the CLI would be refactored to better support adding commands in the future. Each command will accept any of the setup arguments, but may also have its own arguments which are specific to that command. The first argument must always be a command, such as "migrate" or "status".

We've been using md5 for file hashing, which is more or less fine, but cryptographically secure. I've been debating whether that matters. Yes, you can definitely intentionally create md5 collisions if you're being malicious. On the other hand, this is unlikely to be a problem when you're talking about trusted code (hopefully you trust your migrations).

The reason I picked md5 in the first place was to be compatible with the Stack Overflow migrator, but I already do line ending normalization differently, so there's no guarantee that hashes between the two migrators will match. Furthermore, I intend to add a mark-as-run command which will make transitioning from one migrator to the other easier.

Ultimately, there's no particularly good reason to pick md5, and people might question its use in a production environment (whether there's truly any risk or not). I think picking a different hash would be better. SHA-256 is a likely candidate.

Currently, there is no way to change how much gets spit out to the command line. It would be useful to have verbosity levels. Probably the following:

• Minimal: only print high-level actions and results.
• Normal: include setup information (such as db connection info) and results from each SQL command.
• Detailed: include information about each action, including skipped migrations.
• Debug: include stack traces for errors, and any other relevant debug info.

This would be implemented by adding verbosity as the first parameter to Migrator.Log(). Which levels actually get outputted would be controlled by the user either via the Options object, or as a parameter to the Migrator constructor (depending on what is decided in #3). The CLI would have a --verbosity argument.