6 ms·

The docs seem a bit light on the details of what this is doing. It seems like it's keeping metadata about applied migrations with their versions and checksums.

The docs seem a bit light on the details of what this is doing. It seems like it's keeping metadata about applied migrations with their versions and checksums... somewhere. What is this doing under the hood? Also, the docs seem a bit light on the usage details. Can you apply particular migrations? How about a facility to roll back a migration (doesn't seem like it?)

couchand 7y ago
Found the answer to my first question: https://github.com/rust-db/refinery/blob/3096aceb3bf16f90a511edcfa3b5da084025ae7a/refinery_migrations/src/traits.rs#L25 https://github.com/rust-db/refinery/blob/3096aceb3bf16f90a51...
- yebyen 7y ago
  I was going to suggest that, but couldn't find it myself... If this is the same rust migration tool that my Rust friend was telling me about last week, he was saying that it's probably inspired by Rails, as the author came from a Rails background. I'm not certain it is the same one though, as he was describing a system where each migration is both an "up" and a "down" operation, described in separate files, and I don't see that in any of these examples. Rails stores the list of applied migrations in a table like this one. (It could be inspired by Rails, but I'm not seeing any suggestive evidence of that as I'm browsing through the author's other published github repos...) It could also be that I'm misattributing the original idea, and Rails migrations are inspired by migrations from another framework, in another language (maybe Django?)
  - thaunatos 7y ago
    Your friend was probably talking about Diesel migrations: https://github.com/diesel-rs/diesel https://github.com/diesel-rs/diesel
  - amarshall 7y ago
    > he was saying that it's probably inspired by Rails, as the author came from a Rails background You may be thinking instead of Diesel and its associated migration system. Its creator is a Rails ActiveRecord core contributor. http://diesel.rs/ http://diesel.rs/
  - shantly 7y ago
    AFAIK the reason one does this is because one can (in most non-shitty databases cough cough) apply most or all transformations to schema inside a transaction, and also write the current version in that transaction, such that if the transaction completes the risk that the version you think the DB is on and the version it's actually on don't match is minimized, if not eliminated. You can't really get that unless you tie it to the transaction on the DB level, which means writing a version somewhere in the DB, in some fashion.
asdkhadsj 7y ago
> How about a facility to roll back a migration (doesn't seem like it?) Ack, I assumed it was building the rollback based on an understanding of what was applied. If it can't rollback (unconfirmed yet), that is a problem. Bummer
- vmind 7y ago
  Personally, beyond development, I haven't found rollback migrations particularly useful. Once you've run migrations on a live database, it's often much simpler operationally to treat any rollback as a new migration, to keep things append-only. From that perspective, while rollbacks are nice, the technical investment needed to auto-generate sound rollbacks for all DDL operations is probably vastly outsized compared to the benefit, so I can see why it wouldn't be a high priority, especially if targeting multiple databases. If you're writing things by hand, there's not a whole lot of difference between the two.
  - asdkhadsj 7y ago
    That's fair. It never occurred to me honestly, but it's reasonable - especially since I don't think humans can reliably make `down.sql`
    - shantly 7y ago
      Those down files probably rarely receive as much implicit or explicit testing as the up files, too. I sure wouldn't trust them, in most cases.
- jxs 7y ago
  Hi! to roll back a migration you have to build a new one which undo's what you want to rollback. Refinery is very inspired on flyway, which only recently started offering undo migrations, but still explains why that is problematic in it's/our vision: https://flywaydb.org/documentation/command/undo#important-notes https://flywaydb.org/documentation/command/undo#important-no...

couchand 7y ago

Found the answer to my first question: https://github.com/rust-db/refinery/blob/3096aceb3bf16f90a511edcfa3b5da084025ae7a/refinery_migrations/src/traits.rs#L25 https://github.com/rust-db/refinery/blob/3096aceb3bf16f90a51...

yebyen 7y ago
I was going to suggest that, but couldn't find it myself... If this is the same rust migration tool that my Rust friend was telling me about last week, he was saying that it's probably inspired by Rails, as the author came from a Rails background. I'm not certain it is the same one though, as he was describing a system where each migration is both an "up" and a "down" operation, described in separate files, and I don't see that in any of these examples. Rails stores the list of applied migrations in a table like this one. (It could be inspired by Rails, but I'm not seeing any suggestive evidence of that as I'm browsing through the author's other published github repos...) It could also be that I'm misattributing the original idea, and Rails migrations are inspired by migrations from another framework, in another language (maybe Django?)
- thaunatos 7y ago
  Your friend was probably talking about Diesel migrations: https://github.com/diesel-rs/diesel https://github.com/diesel-rs/diesel
- amarshall 7y ago
  > he was saying that it's probably inspired by Rails, as the author came from a Rails background You may be thinking instead of Diesel and its associated migration system. Its creator is a Rails ActiveRecord core contributor. http://diesel.rs/ http://diesel.rs/
- shantly 7y ago
  AFAIK the reason one does this is because one can (in most non-shitty databases cough cough) apply most or all transformations to schema inside a transaction, and also write the current version in that transaction, such that if the transaction completes the risk that the version you think the DB is on and the version it's actually on don't match is minimized, if not eliminated. You can't really get that unless you tie it to the transaction on the DB level, which means writing a version somewhere in the DB, in some fashion.

asdkhadsj 7y ago

> How about a facility to roll back a migration (doesn't seem like it?) Ack, I assumed it was building the rollback based on an understanding of what was applied. If it can't rollback (unconfirmed yet), that is a problem. Bummer

vmind 7y ago
Personally, beyond development, I haven't found rollback migrations particularly useful. Once you've run migrations on a live database, it's often much simpler operationally to treat any rollback as a new migration, to keep things append-only. From that perspective, while rollbacks are nice, the technical investment needed to auto-generate sound rollbacks for all DDL operations is probably vastly outsized compared to the benefit, so I can see why it wouldn't be a high priority, especially if targeting multiple databases. If you're writing things by hand, there's not a whole lot of difference between the two.
- asdkhadsj 7y ago
  That's fair. It never occurred to me honestly, but it's reasonable - especially since I don't think humans can reliably make `down.sql`
  - shantly 7y ago
    Those down files probably rarely receive as much implicit or explicit testing as the up files, too. I sure wouldn't trust them, in most cases.
jxs 7y ago
Hi! to roll back a migration you have to build a new one which undo's what you want to rollback. Refinery is very inspired on flyway, which only recently started offering undo migrations, but still explains why that is problematic in it's/our vision: https://flywaydb.org/documentation/command/undo#important-notes https://flywaydb.org/documentation/command/undo#important-no...