Description
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.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
Participants
Activity
avakarev commentedon Jun 4, 2023
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 withreturn nil?maroux commentedon Jul 9, 2023
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 thattableAis created as the first migration, say201608301400, so that your test environment is set up using this tool rather than manual SQL queries. However, if you do that,201608301400can't be applied to your existing database, because it'll find thattableAalready exists. To get around this problem,--fakeflag would fake apply201608301400- 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():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.