There's no protection against trying go backwards through versions, e.g. imported first with 0.9.0, then with 0.8.0. While users hopefully aren't doing that intentionally, it's not hard to imagine scenarios that could happen accidentally. (e.g. someone references older procedures)
I think adjusting the get_prior_import() function to return pgosm_flex_version in the results would make this easy enough to add a check for. The column stores values such as 0.9.0-50c6ddd. Will need to split the PgOSM Flex version from the commit hash. Right now I'm just thinking of the PgOSM Version, not the commit hash. That's not perfect, but users of --replication generally should not use the :latest Docker images, only the tagged versions.
To add the second check we'd need to internally track those official hashes and that sounds like a lot of extra maintenance overhead it'd be easy to forget or otherwise screw up.
Details
There's no protection against trying go backwards through versions, e.g. imported first with 0.9.0, then with 0.8.0. While users hopefully aren't doing that intentionally, it's not hard to imagine scenarios that could happen accidentally. (e.g. someone references older procedures)
I think adjusting the
get_prior_import()function to returnpgosm_flex_versionin the results would make this easy enough to add a check for. The column stores values such as0.9.0-50c6ddd. Will need to split the PgOSM Flex version from the commit hash. Right now I'm just thinking of the PgOSM Version, not the commit hash. That's not perfect, but users of--replicationgenerally should not use the:latestDocker images, only the tagged versions.To add the second check we'd need to internally track those official hashes and that sounds like a lot of extra maintenance overhead it'd be easy to forget or otherwise screw up.