How to run a specific migration file?

Is there a way to run a specific migration if I have multiple scripts living in my migrations/ folder? Lately, I have had a few use cases where I need to re-run a script whose entry is already in the fireway collection on Firestore. However, to actually make a script to be executed, I have found that I have to manually delete the entry corresponding to that script and others that came after it. For example, let’s say I have:

migrations/v0.0.1__first_migration.js migrations/v0.0.2__second_migration.js migrations/v0.0.3__third_migration.js

If I need to run just v0.0.2__second_migration.js, I have to delete both the corresponding v2 and v3 entries in the fireway collection and then rerun fireway migrate. Wouldn’t it be nice if I could do something like fireway migrate --script=v0.0.2?

[kevlened]

fireway only does roll-forward migrations

I understand, by the way what is the underlying reason for this current limitation? In any case, it’d be very nice if there was a way to do roll-backs, like alembic does. I know we’re not in SQL land here but I’m allowed to dream, right? 😄

I wouldn’t stop your dream! However, the NoSQL limitation is exactly the reason. I saw an idea for firestore migration rollbacks by @gregdingle, but I don’t plan on overhauling fireway for this flow.

There are times when I have had to rerun a migration because some older code was still being run, and it wrote data in the old schema/format.

Makes sense. To be successful in NoSQL, your client and server code needs to know how to handle multiple schemas (especially if you have mobile clients). You may be able to get around this with a fancy mapping of old to new properties on the server-side. Migrations don’t solve the problem unless you have downtime, because there’s no way to apply a migration atomically for large collections in firestore. In short, this is always going to be a problem, so your clients and server have to handle all old schemas until you’re certain there are no more old clients.

If you’re iterating on a migration, use --dryrun to ensure you don’t modify the production db.

At the moment --dryrun is not working for me - regardless of my use of it, the changes are being applied to the records but the fireway collection entry is not added. I am also impacted by this related issue

I haven’t been able to reproduce this problem. I would look for places that don’t use the firestore instance that fireway returns. This includes models you may be trying to share with your clients.

[kiptoomm]

@kevlened any insights on the above questions?