Support int8 migration versions via new int8-versions feature #330
Conversation
mpalmer
force-pushed
the
int8-versions
branch
4 times, most recently
from
d8252fe
to
1277e3e
Compare
This addresses, though does not really *fix* rust-db#83, because it doesn't make refinery support timestamped migrations *by default*, but only if you opt-in to the new feature. However, making it an optional feature neatly sidesteps the unanswered questions in the issue, and so makes the implementation easier to complete and land.
There was a problem hiding this comment.
Hi, and thanks for your interest! As I stated on #83 (comment) I'd rather this was not feature gated and instead a function was provided to migrate to int8. Would you be willing to do that instead?
Thanks
| #[cfg(not(feature = "int8-versions"))] | ||
| pub type SchemaVersion = i32; | ||
| #[cfg(feature = "int8-versions")] | ||
| pub type SchemaVersion = i64; | ||
|
|
There was a problem hiding this comment.
features in Rust should be additive not mutually exclusive, enabling --all-features should not break compilation, see here
There was a problem hiding this comment.
Enabling --all-features doesn't, as far as I'm aware, break compilation. CI is all green.
Not at the present time, no. As you identified in #83, there are unanswered design questions with migrating existing users to an int8 column, I don't use the CLI, and the approach in this PR Works For Me(TM). Perhaps one of the commenters from #83, such as @ankhers, might like to use this PR as a basis? |
jxs
force-pushed
the
int8-versions
branch
3 times, most recently
from
fb26681
to
666cbd3
Compare
This addresses, though does not really fix #83, because it doesn't make refinery support timestamped migrations by default, but only if you opt-in to the new feature. However, making it an optional feature neatly sidesteps the unanswered questions in the issue, and so makes the implementation easier to complete and land.