Possible semantic versioning order issue at double-digits

[harry-graham]

Hi, we seem to have encountered an issue with migration ordering in our project.

We've got database migrations from V1_1_0 up to at least V1_13_0 in our project, but we've just noticed that in the database itself, the migrations have been ordered differently to what we were expecting.

Expected

We were expecting that 1.9.0 -> 1.10.0 -> 1.11.0, based on https://semver.org/#spec-item-2:

A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

Actual

However, we're actually seeing: 1.1.0 -> 1.10.0 -> 1.11.0 -> 1.2.0 -> ....

---

Is this expected behaviour?

[marianozunino]

@harry-graham it is not.

[harry-graham]

@marianozunino thanks for looking into this so quickly! 🙌🏼

If we completely wipe the database and start fresh with 0 migrations, and run all migrations at once, then the migrations get run in the correct order.

However, when we try to run the migrations command again, even if there aren't any new migrations to run, then the command crashes.

In our example:

• We have migrations V1_0_0 up to V1_13_0
• On the first attempt, they all get run in the correct order as desired
• On any future attempts, the migrations command attempts to first execute migration V1_2_0 again as the next migration to run
  • This crashes because the node already exists in the database for that migration

It might be that it sees "V1_13_0" as the latest applied version, but then still sees "V1_2_0" as being a candidate migration?

[marianozunino]

@harry-graham can you test this branch before I merge it?

I found the bug that you described, but I want to make sure that everything else works just fine. The info command was miss sorting the migrations as well.

https://github.com/marianozunino/morpheus/tree/25-possible-semantic-versioning-order-issue-at-double-digits-1

[harry-graham]

@marianozunino thanks! 😃

I've not tested a branch before (as was just testing the latest release locally), but will have a look into it now.

[marianozunino]

Clone the repo, checkout the branch and execute this command

npm i; npm run build; node dist/main.js

[harry-graham]

@marianozunino thanks for the instructions, that worked 👍🏼

I've tested with the new branch, and it resolves the previous issue we were seeing, thanks! 🙌🏼

---

For reference (even if just my own later on), to test this locally, I had to:

• Clone the repo
• Checkout the relevant branch to test
• Run npm i
• Run npm run build
• Back in the project to test it against, run npm install --save path/to/file (see this StackOverflow answer) to use the local version of the dependency

[marianozunino]

For reference (even if just my own later on), to test this locally, I had to: ...

Here's another way if you want to test it as you did:

npm i; npm run build; npm pack

pack creates a tgz that contains the code that would be released by npm publish. So given that, then you can npm install path/to/morpheus4j-x.y.z.tgz

That's the closest to testing the code as if it were released.

Thanks so much for testing it.