Allow fake migrations

[maroux]

Having recently discovered this project, and trying to migration an existing project - I realized a blocker for migrating existing project for a lot of people would do fake migrations.

I'd model this against Django, which describes it as:

Marks the migrations up to the target one (following the rules above) as applied, but without actually running the SQL to change your database schema.

This is intended for advanced users to manipulate the current migration state directly if they’re manually applying changes; be warned that using --fake runs the risk of putting the migration state table into a state where manual recovery will be needed to make migrations run correctly.

I shouldn't have to manually muck around with SQL queries when integrating this library.

I can take a stab at it if this looks like a reasonable feature.

[avakarev]

Hi @maroux,
thank you for your contribution.

It was quite a while when you created the issue and got no response so far. Sorry for that.

Can you please explain, ideally with code example, what's the use case for fake migrations? When you migrate existing project, why it's not possible to use .InitSchema() to provision initial schema state? Or why migration function can't be conditional or just be mocked with return nil?

[maroux]

Hi @avakarev

The use case is adding gormigrate to an application that already has a database, say tableA. Ideally when you set up gormigrate, you'd want to set up migrations such that tableA is created as the first migration, say 201608301400, so that your test environment is set up using this tool rather than manual SQL queries. However, if you do that, 201608301400 can't be applied to your existing database, because it'll find that tableA already exists. To get around this problem, --fake flag would fake apply 201608301400 - that is, it will mark the migration as having being applied without performing actual database operations. Thus, your existing database and your new migration table will be in-sync from that point onwards.

Looking the usecase for .InitSchema():

when you are deploying a new instance of the app, in a clean database

This doesn't match what I'm describing. In my use case, the database and tables already exist, I'm trying to now integrate into gorm / gormigrate. Hope that helps.