Couple questions

[meh]

What's the status of this? Today I went through all the migration tools/libraries I could find for Rust and this seems to be the one I like the most.

And could there be a chance of turning this into a library as well so I could, for example in the executable for a backend service, check if all migrations have been applied and exit if they haven't?

Thanks for working on this.

[byronwasti]

Hey, sorry for the late reply (notification settings were all messed up). This project is an MVP right now and can handle basic use-cases. I've been using it for various personal projects, but it is definitely a project in the early stages. (ie. the errors are pretty bad and it hasn't been thoroughly battle-tested).

I'd be happy to reconfigure things so that this can work as a library as well (I imagine that will be rather quick). Since there seems to be some more interest in this project recently, I'll likely spend some time cleaning up the documentation & errors.

[meh]

I've been using it for a couple projects and aside from wanting some more configuration options (like loading database from the .env) and a couple small annoyances it's still very usable.

May I also suggest joining forces with sqlx? They seem to have some strong opinions on migrations too and having the best migration tool available within sqlx would make things easier for me and other sqlx users :P

[byronwasti]

Glad to hear it has mostly been working out for you. I can look into adding .env support if you don't mind describing how you're using it. Also happy to hear any small annoyances you have and try to get them fixed!

I have also pushed a few updates and there should be easy library support. You can find the examples for it in the README. The configuration format has also changed (which might catch you off-guard), but I'm hoping that it makes things nicer long-term.

I'm happy to support inter-op with sqlx, although I believe the two projects should work just fine together as-is (so long as movine is run from the CLI). I'm not entirely sure how library inter-op could work, since sqlx does all of its magic at compile-time and I imagine compile-time migration running would not be great.

Let me know if anything else comes up or if documentation is too sparse in any given area. I'll try to spend some more time this weekend adding some docs.

[meh]

Right now in my backend thingy I have a .env file with, among other things, a DATABASE_URL field that looks like this: postgres://user:password@localhost/database, then clap does its magic and if no --database argument is provided it loads it from the .env, so having the same in movine would be great, i.e. pass by parameter and load from .env if not present.

One small annoyance I've had, which is very likely my fault, is when trying to initalize migrations on a new database/server/whatever doing movine up rightfully complains of no migration table, but doing movine init complains about migrations/ already existing, so what I end up doing is this:

mv migrations/ /tmp
movine init
rm -rf migrations
mv /tmp/migrations/ .

I've had some issues with redo, where I ended up in a state where I had to drop the database and do the movine init dance again, but I probably misunderstood what redo does, usually I just go with movine fix and everything is happy.

Documentation wise I haven't really had any issues, when I had doubts I ended up just reading the source code, I'm probably not the best person as A/B test for docs since I'm used to diving into the source code for things rather than reading them :panda_face:

[byronwasti]

Awesome, thanks for going into detail about things. I will look into loading from the environment like that; I agree that would be a nice thing to have.

I have fixed the movine init issue, and it should no longer cause issues when you run it while the migrations/ folder already exists. Let me know if you continue to run into issues with that!

The redo command was sadly buggy, but I fixed it and added a regression test. I've been refactoring the internals pretty heavily so I must have missed breaking it and the existing test wasn't very good.

[meh]

A couple notes from looking at the librarification changes, I know it's work in progress.

What I need public but in a nicer API is status that gives me the iterator of migrations.

And a way to just get the queries without having to create a specific connection for migrations.

So basically a "prepared" version of queries or something.

[meh]

Oh yeah, and it would be nice in case of error while running a migration to get printed also the migration that caused the error, and maybe more context if available, like where the syntax error is.

[byronwasti]

I can look into exposing something like that, although I'm not entirely sure that is within the scope of functionality I want to expose with Movine.

And the migration errors are directly from the database adapter crates, which are in turn from the database outputs. I do agree it makes sense to say which migration its working with, so I'll add that in.

[byronwasti]

I'm going to close this out for now. DATABASE_URL support and environment variables are now landed with help from another contributor, so hopefully that's useful. Thanks!