New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Step towards automatically reversible migrations #1583

Closed
moore3071 opened this Issue Mar 3, 2018 · 2 comments

Comments

Projects
None yet
2 participants
@moore3071

moore3071 commented Mar 3, 2018

It would be nice if Diesel could get to a place where the user doesn't need to write the down function. This is at a glance a very difficult problem when migrations are purely SQL, and in fact ActiveRecord and Django's ORM have their migrations written as code.

The best route for Diesel to (generally) eliminate the need for down is to add a modified query builder for migrations. I'd imagine that this would make four possibilities for what's included in a migration directory:

  1. up.sql and down.sql for backwards compatibility
  2. migration.rs for a migration that Diesel can reverse (this could be up.rs for consistency)
  3. up.rs and down.rs for a migration that Diesel's query builder can handle reversing, but Diesel can't figure out how to reverse
  4. up.rs and down.sql for a migration that Diesel can't figure out how to reverse
  • I have already looked over the issue tracker for similar issues.
@sgrif

This comment has been minimized.

Member

sgrif commented Mar 3, 2018

This has been discussed at length (I think it's usually been in the context of "I want Rust migrations" rather than this, but in my eyes the only reason to have Rust migrations is for auto-revert).

Ultimately based on my experience maintaining Rails, I don't think that the value gained by getting revert for free outweighs the maintenance cost of having a Rust DSL for migrations. It's been a hotspot of bugs for Rails for the entirety of my involvement with that project, and the DSL still only handles a small subset of what is possible in SQL.

That said, I designed our migration API to allow for other forms of migrations to exist, and have set up plans for how third party crates would add new forms. Barrel is looking like it will be the first external migration system to do that integration. While I'm happy to help implement non-SQL migrations and have the small amount of code in Diesel required to integrate third party crates that do so, I do not think this feature makes sense for Diesel itself at this time.

@sgrif sgrif closed this Mar 3, 2018

@moore3071

This comment has been minimized.

moore3071 commented Mar 4, 2018

Thanks for the quick response. The extensible route of allowing other crates to provide new migration formats is probably the best route; I'll be sure to check out Barrel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment