Migrate: Migration hooks

[divyenduz]

This issue tracks the implementation of https://github.com/prisma/specs/tree/master/lift#hook

[matthewmueller]

internal note: Dropping for this sprint. Push it back for 2 weeks

[RafaelKr]

Hey guys, I think I will need this feature in the near future.

Also it looks like something that's not that hard to implement.
I have some free time in the next two weeks and I would like to offer to write a basic implementation which runs the hooks after lift up/down.

Did you have any thoughts of how you would like to build it?
Especially how the difference between up/down should be handled. My thought about this is an environment variable, e.g. LIFT_DIRECTION, which either says up or down. I have just read through the entire lift specification and found that it is already defined, fortunately in line with my thoughts.

If you're interested and have time to discuss this topic now, just hit me up on Slack to exchange some more details: @RafaelKr

Edit on Dec 30:
removed the striked-through part

[RafaelKr]

I just thought about a workflow for managing the hook files while they are work in progress (i.e. before saving the migration with prisma2 lift save).

I could imagine that it would be helpful if you can create the files directly in the prisma/migrations folder. So you can adjust them over time while making changes to your schema. They aren't executed automatically. When running prisma2 lift save they would be automatically moved to the new migration folder.

An alternative location for the WIP hook files could be prisma/migrations/dev.

[RafaelKr]

I've just took the time to read through the entire lift specification and clearing out my head about it in this comment.

I noticed it says "Spec: Outdated 🚨". Is the part of the spec that defines the hooks up-to-date?

There is an item in the "Unresolved questions" part which says Spec out how migration "hooks" are working (e.g. before.up.sql) as it's depending on individual connectors. I currently don't exactly understand that one. Is that question out-of-date?
My understanding of it is that this one is only related to hooks with a .sql extension. I also think that it shouldn't be possible to use raw SQL files as hooks, at least not when first implementing it.
And in hook scripts (Shell/JavaScript/Go/...) the developer/the prisma client can take care of what should be applied to which datasource.

My current plan of implementing this would be the following:

• Get familiar with the code base related to executing migrations.
• Implement all types of migration hooks as speced yet.
• The spec says when a migration script fails, it should rollback the transaction. I need to find out two things for this:
  
  
  
  • When the before script fails: How to abort the started migration with useful user feedback
  
  
  • When the after script fails: How to rollback the transaction and abort the migration with useful user feedback
  
  

It would be nice if someone who is very familiar with the lift code base and docs could point me to the right places where I can find the important code parts with which I would have to work with.

[janpio]

I noticed it says "Spec: Outdated 🚨". Is the part of the spec that defines the hooks up-to-date?

Most probably not. Lift is currently not the focus of our implementation (and spec) work.

We appreciate your thoughts here though and will consider them when this changes and we start thinking about how to implement and finish our migration story. (No ETA though right now.)

[Aetherall]

Hey guys, Is it possible to have the progression status of this feature ?
It is kind of necessary in order to preserve data consistency between model migrations..

Also, it is an advertised feature on the github readme and therefore in the npm page of @prisma/migrate, but there is no entry in the documentation

Anyway, keep up good work !

[tomhoule]

Since migrate hit preview (2.13.0), migrations are imperative. There shouldn't be a need for hooks anymore. If you have ideas around hooks that would be relevant to newer versions of migrate, please create a new issue for your feedback. Thanks!