Support for making Order scoped on System Version

[siegenthalerroger]

We are trialing Mongock at our company and are running in to a few pain points surrounding the ordering of ChangeUnits.

We're confused as to why the order property is considered independently of the systemVersion. In our opinion this results in an unncessary duplication of the systemVersion in the order property, to ensure that migrations introduced in later sytem versions are always executed after older ones.

We'd like to suggest adding an option to have the ordering of ChangeUnits be dependent on the ordering of the systemVersion AND the order property.

This is related but not the same as https://github.com/mongock/mongock/discussions/671

[dieppa]

Hello @siegenthalerroger ,

I answer #671 here.

The systemVersion is a legacy feature we have been forced to carry on with. It's basically a filter when applying the changeUnits, nothing else. It was a very corner case for some consultancy. e are considering to deprecated(need to analyse the use and impact)

However, the order, as you mention is alphabetical and we have found that's not what everyone expects. I like your suggestion of allowing to provide custom Comparators.

Right now, we are a bit tight in terms of bandwidth, would you like to raise a PR and I'll review asap?

[IsNull]

Some situations that the system version & filtering could be useful:

• A project may produce a lot of Change Units over time. If you deploy a mature project to a new site / customer all previous Change Units would be initially processed even though it would not be necessary. Filtering a min System Version would prevent this.
• Another use case could be able to deploy a service to production but disable the migration. A max System Version would allow this.

Having a filter and order property separated is probably not the ideal situation and thus I understand why you want to deprecate the systemVersion.
However, I could imagine to combine the two features: Instead of an order property and a separate systemVersion, both could be combined to a semver sortable and filterable property. One would specify systemVersion="12.10.3", and could filter by semver ranges such as >=12.10.x. Order would also be derived from the semver spec. Just as an idea.

In any case, it would make sense to await your decision if the system version will be supported in the future and how the above concerns should be addressed without it.

[dieppa]

Thanks, @IsNull , we were considering to deprecated, but it's worth noticing, that the systemVersion doesn't really hurt(although the name is not that intuitive, and I'd even say wrong. If I could come back in time, I would have picked something like ceiling and ground or similar), so we will probably keep it and rename it the next major version(although keeping the systemVersion as deprecated for backward compatibility)

So having that into account, how are you feeling about raising a pr to allow custom comparators, @siegenthalerroger ?

[siegenthalerroger]

We'd need to look into our bandwidth and get back to you on this. Thanks for the clear communication and readiness for a PR on the matter.

[dieppa]

Thanks. We think it's a valuable addition 😃