Support loading scripts from embedded resources

[mhelleborg]

Add support for using scripts directly as embedded resources.
This simplifies some use cases and makes sure the script can be referenced the same way in all environments.

[lecaillon]

Hi, I don't have feedback where have files in a script folder is a problem either on Windows or Linux. More over hide the scripts in the assembly goes against the simplicity and the transparency goal of Evolve IMO.

[GeirGrusom]

My cases:

1. Embedded resources won't get confused by application shadowing or other such monkey business (we have an application that has made it exceptionally awkward to find file relative to the application).

2. Migrations scripts should not be altered by hand on-site, and embedded resources makes sure that doesn't happen without developer intervention.

Simply put I think it makes it easier to deploy. Also flyway supports loading migration scripts from the jar.

[ld0614]

I think this is a good option and would have avoided my issues in #76

[jouana]

Hi everyboby,

It should be cool to have this feature.

We have a WPF application with SQLite, this feature should help us for many way.

Regards.

[mhelleborg]

@lecaillon Is this something you would accept a PR on? If so, I could prioritize implementing it against the current version

[CaueArua]

This feature is exencial when you build an application that will run on client. If you expose the spl you have a major security breach.
Please implement this feature.

[modernist]

+1. I totally agree this is a useful feature. @lecaillon @mhelleborg if any help is needed to move this forward towards a release let me know, it's been almost a year since the PR was opened.

[lecaillon]

Let me release the Evolve 2.0 version.
It's a major rework of Evolve to help simplify the overall design.
When it's finish it should let me a lot more time to add new features like this one. Promess ;)

[lecaillon]

@GeirGrusom @ld0614 @jouana @modernist @CaueArua

Actively working on it for the next release: Evolve 2.1.0
Thanks to @mhelleborg for its PR that helps me a lot.

I have to implement it in Evolve, but also in Evolve.MSBuild and the CLI.
Shoudn't be too long though.

Usage

try
{
    var cnx = new SqliteConnection(Configuration.GetConnectionString("MyDatabase"));
    var evolve = new Evolve.Evolve(cnx, msg => _logger.LogInformation(msg))
    {
        Locations = new[] { "ConsoleApp1.db.migrations" },
        EmbeddedResourceContext = Assembly.GetExecutingAssembly()
    };

    evolve.Migrate();
}
catch (Exception ex)
{
    _logger.LogCritical("Database migration failed.", ex);
    throw;
}

Feel free to give me your feedback

[mhelleborg]

@lecaillon You could improve upon my original interface with a list of assembly / locations, instead of the single EmbeddedResourceContext. I think that would be better than overloading the file locations, and would support potentially loading scripts from multiple assemblies. It also makes the interface contract less ambigous :)

[lecaillon]

@mhelleborg You think in this case something like ResourceFilters is more suitable than Locations ?
So you would have 2 new properties:

• EmbeddedResourceLocations
• EmbeddedResourceFilters

[mhelleborg]

@lecaillon I was more thinking sending in a list of assemblies with a set of locations each. More or less a tuple of assembly and list of locations.

Alternatively, just let the user provide a lambda which returns an IEnumerable of migrations. Then they can be loaded from anywhere

[lecaillon]

@mhelleborg I need to find a structure easy to use via json or web.config/app.config files for Evolve.MSBuild, or via command line options for Evolve.CLI
So 2 lists of strings separated by ; seemed a good idea

Thus it implies you cannot filter migrations script by assembly. It is a general filter. That's why at first I thought to allow only one Assembly to avoid confusion

[lecaillon]

@mhelleborg I think I will going to keep the EmbeddedResourceContext to avoid confusion with the EmbeddedResourceLocations term used by file migration scripts. So:

• Assembly[] EmbeddedResourceContexts: one or several relative or absolute pathes to assemblies to scan
• string[] EmbeddedResourceFilters: zero or multiple filters to apply when searching for embedded migration scripts

In Evolve.MSBuild or Evolve.CLI those 2 properties will be a list of string where values will be separated by ;

Everyone's ok with that ?

[mhelleborg]

@lecaillon I think I would prefer having a cleaner API, and maybe drop the functionality from the CLI. I think most of the value proposition for me is using Evolve from code, but other people might have other use cases :)

[lecaillon]

Or...

• EmbeddedResourceAssemblies
• EmbeddedResourceFilters

;)