Using dbmigrate programmatically -> why is it not a lib/why is functionality not in dbmigrate-lib

[ghost]

Hello!

Consider myself a noobie, please.

I am (successfully) using your awesome migration tool (thanks for that!) programmatically in an application of mine.

To get it working I had a look at your implementation of dbmigrate (as suggested in the readme) and basically more or less re-implemented the same macro and functions myself.

dbmigrate is not a library (correct me if I am wrong and simply too dumb to get the crate somehow).

That leaves me with 2 questions/proposals:

Can it be done that functionality (e.g. migrate macro and up etc. functions) be moved to dbmigrate-lib?

If not (I would be curious as to the why then, actually really curious why they were done in the dbmigrate - as said, consider myself a noobie!), could dbmigrate be also made a lib?

Thanks again for your time and efforts!

[Keats]

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.

[Keats]

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

[ghost]

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)

[Keats]

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

[sivakov512]

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

[Keats]

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

[sivakov512]

Why you stop using it?

but I will merge a good implementation of that issue

You mean that I can contribute with PR?

[Keats]

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!

[sivakov512]

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

[sivakov512]

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

[ghost]

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

[ghost]

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

[Keats]

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

[sivakov512]

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?

[Keats]

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

[sivakov512]

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