Using dbmigrate programmatically -> why is it not a lib/why is functionality not in dbmigrate-lib about dbmigrate HOT 16 OPEN

Hey
I agree that some of the functions in dbmigrate should probably be in dbmigrate-lib. It's mostly due to the fact that dbmigrate started as a binary only and some parts of it moved to a lib later on but I didn't move everything. I'll do that over the weekend, should be a simple case of copy/paste and publishing a new release.

from dbmigrate.

I just saw the reason why I didn't move the code to the lib, it has lots of println! in the middle which you don't want when using as a library. It also uses a print crate for it which you want even less as a lib

from dbmigrate.

The question is why that is tied to the print crate in the first place. One could simply return Result and let the user of the lib handle it appropriately. (For dbmigrate that would mean using the print crate)

from dbmigrate.

I guess the migrate macro could be turned into a function into dbmigrate-lib but the others cannot just be changed to a Result that easily. For example, up and down will need to return a Vec<Result<_>> since it can run many migrations in one go

from dbmigrate.

Any news here? I want to use dbmigrate programmatically but it requires copy\paste from dbmigrate crate into my project.

from dbmigrate.

I don't use that crate myself but I will merge a good implementation of that issue

from dbmigrate.

Why you stop using it?

but I will merge a good implementation of that issue

You mean that I can contribute with PR?

from dbmigrate.

Why you stop using it?

I don't do anything database related right now with Rust.

You mean that I can contribute with PR?

Yep!

from dbmigrate.

Oh, it requires a lot of refactoring, if I understand correctly?

from dbmigrate.

How can we organize this work so that I don’t do a very large pull request for review at once?

from dbmigrate.

I wrote some code a while back, didn't come around to get it ready for a PR yet. Tested with SQLite and Postgres, but not with MySQL: https://github.com/FSMaxB/dbmigrate/tree/simplify-migration-struct

from dbmigrate.

This relates to #38 which makes it easier to use the library programmatically since you don't need to check for None-Optionals everywhere.

from dbmigrate.

Yep #38 is a great way to start. After that, the changes should not be THAT big.

from dbmigrate.

I think that we should start with move code with current implementation into lib as much as we can. Right?
Is not sure #38 is relevant here. Could you please explain it?

from dbmigrate.

#38 is just simplifying the code, not strictly required but it makes it easier to think about.

from dbmigrate.

You think that with this refactoring we should not only move code into lib?

from dbmigrate.