install takes the old version, not the version being installed

[zachdaniel]

We fixed a bug in ash_postgres where it was doing the wrong thing here, so it makes sense that this broke, but the solution is to fix downstream extensions.

[moissela]

I think is more clear that the install function argument indicates the version to generate the migration of, rather than the previous version from which you are coming.

My original inspiration for this come from here.

Currently, AshPostgres is not calling every intermediate version between the previously installed one and the latest available one, so it is still install function's responsibility to generating a valid migration even if some intermediate versions are skipped.

What do you think? Maybe there are other motivations around this change that I'm not aware of?

In relation to this, I open a PR to AshPostgre here which restore this behaviour correctly.

[zachdaniel]

I've addressed the PR you mentioned just now. It's intentional that we provide the old version of the extension that the user is on. As you make changes, you're meant to update the relevant migration functions to provide a minimal migration path from wherever the user was before. Without it, you can't know what changes must be made.

[moissela]

Okay, now I understand what you mean!

The current version of an extension correctly defines the current state (identified by the attribute latest_version) and exposes a specific install method to be able to reach the current state from any previous version in the most optimized way possible.
If the extension had never been used in the user's project before, then AshPostgres calls install(0) indicating that it wants to obtain the path from nothing to the current version.

Got it, thanks for your time!

[zachdaniel]

Yes, exactly 🥳