Run Same Migrations Against Multiple Schemas

[Joel Mason]

Hi,

I'm new to FM and still trying to get my bearings.  Seems like a really great project though.  I'm trying to apply the same migrations to multiple schemas.  Each schema is a tenant in our single instance application.  The problem I'm hitting is that the migrations run perfectly on the first tenant, but after that it seems they aren't running because the VersionInfo table already says they were run (duh...).  I've tried playing around with the table some, but can't quite figure out what it is I'm looking for.  I think what I would like is to have a VersionInfo per tenant (schema).  Is this possible?

Thanks for your input,

Joel

[Michael Powell]

On Friday, May 29, 2015 at 5:37:11 PM UTC-4, Joel Mason wrote:

Hi,

I'm new to FM and still trying to get my bearings.  Seems like a really great project though.  I'm trying to apply the same migrations to multiple schemas.  Each schema is a tenant in our single instance application.  The problem I'm hitting is that the migrations run perfectly on the first tenant, but after that it seems they aren't running because the VersionInfo table already says they were run (duh...).  I've tried playing around with the table some, but can't quite figure out what it is I'm looking for.  I think what I would like is to have a VersionInfo per tenant (schema).  Is this possible?

Besides, I ended up rolling my own migrations to have more control over things like this...

Off the top of my head, why not have a base class with the general migration pattern. Not sure how you specify the schema; Fluent NHibernate, for instance, allows Schema to be specified.

Then the tenant (schema) specific migration derives from the boilerplate code, which is also specifically versioned (somehow; again, I ended up rolling a System.Version based migration pattern).

Assuming you can isolate Schema from the boilerplate, this should be quite doable.

P.S. I wanted more control over the SQL-ness of the migration and was finding that for anything more than run-of-the-mill add a column here, drop a table there, migrations, FM wasn't quite up to it. Plus with not a lot of code, it's fairly straight forward to put EF (current versions) to work in this area.

HTH

[Joel Mason]

So I figured out what I needed to do.  I created a new VersionLoader called TenantVersionLoader.  I set this on the runner right before I run it.  Inside the TenantVersionLoader I set the schema and index name using the tenant.  This places a version table on every schema how I want it.  Hope this helps someone else.

Take Care,

Joel