Diesel migration fails to apply schema patch.

[adsnaider]

Setup

Versions

• Rust: 1.58
• Diesel: 1.4.8
• Database:
• Operating System: Linux (PopOS)

Feature Flags

• diesel:

Problem Description

Diesel fails to apply the patch. It seems to be an issue with recent_crate_downloads. AFAIK, there isn't a way to manually apply the patch or fix the issues so it's unclear how to make any progress.

What are you trying to accomplish?

Setup a new table in crates.io

What is the expected output?

The migration runs successfully.

What is the actual output?

Can't apply the patch.

Are you seeing any additional errors?

No.

Steps to reproduce

Clone crates.io and follow the instructions in docs/CONTRIBUTING.md to setup up for backend development.

Assuming everything builds with cargo build, create a new migration named create_sessions (name won't matter).

Setup the migration files as follows:

up.sql

CREATE TABLE sessions (
  id SERIAL
      PRIMARY KEY,
  user_id INTEGER NOT NULL
      REFERENCES users,
);

down.sql

DROP TABLE sessions;

Run diesel migration run.

Checklist

• I have already looked over the issue tracker and the disussion forum for similar possible closed issues.

• This issue can be reproduced on Rust's stable channel. (Your issue will be
  closed if this is not the case)
• This issue can be reproduced without requiring a third party crate

[weiznich]

From diesels side everything seems to work as expected here. Diesel cli tries to apply the patch file to the newly generated schema and fails due to merge conflicts. There is no way for us to automatically apply the patch in such situations, therefore the error message. Closed as this is not a bug.
Feel free to use the gitter channel or the discussion part of this repository to ask for help. Our issue tracker is reserved for bugs and other technical things related to the development of diesel itself.

[adsnaider]

I understand but given that this is the only workflow available with no way to recover from errors (as far as I can tell), maybe the diesel team should come up with a way to handle situations like this one. As a user, I don't expect my migrations not to work due to "patch" conflicts. Maybe the problem is that diesel uses patch files, or that there's no workflow to resolve the conflicts if they do happen. Maybe there's no better way, I don't know.
Maybe in case of conflicts diesel can ask the user to resolve the conflicts manually, after which diesel can store a snapshot of the resolved file for future migrations and reruns ¯_(ツ)_/¯

Just FYI, I managed to work around this by changing the table name in the migration. But you can imagine why I may not want to do that.

[weiznich]

It would be great to see improvements here, but we do not have the capacity to implement larger improvements here. That written improvements to the existing workflow are definitively welcome. Please open a new discussion thread outlining the basic idea, if someone is interested to work on concrete proposals.