Duansg commented on PR #4368: URL: https://github.com/apache/hertzbeat/pull/4368#issuecomment-5568677843
@zqr10159 Both points are addressed in 32895b0aed. **1. Stale identifiers removed.** The three V190 headers now read only `Schema changes for release 1.9.0.` plus a note that every statement is re-runnable; `V181/V182/V183` are gone from the scripts, and so are the issue references. `FlywayConfigurationTest` no longer mentions `version 181`. The RC/snapshot history-cleanup section is dropped from the PR description. **2. The proof is committed and CI runs it.** `hertzbeat-startup/src/test/.../migration/` — picked up by the existing `backend-build` job, which already runs `-Dmaven.test.skip=false` on a Docker-capable runner, so it is a merge gate and not a job that has to be wired up. - `MigrationInventoryTest` (no Docker): every dialect ends V180 → V190, no V181/V182/V183, all three dialects ship the same versions each exactly once, no stray file in a migration directory. - `AbstractMigrationUpgradeTest` + one subclass per dialect: Hibernate `ddl-auto` builds the schema from the scanned entity model — same `@EntityScan` package and the same naming strategies Spring Boot applies — and Flyway runs after it, the way `FlywayConfiguration` orders them. The database is taken to the last released **V180** state first, so the scenario is the upgrade a 1.8.0 user performs, not a synthetic one. Flyway is configured by reading `spring.flyway` out of the shipped `application.yml` rather than a copy, so the regression cannot drift from what the application runs. On Flyway-first: it is not a supported ordering and the test does not pretend otherwise. V160 and V180 shipped assuming Hibernate-created tables — on an empty database V180's first statement is an unguarded `UPDATE HZB_ALERT_DEFINE`, which cannot work. What is worth covering is the part of that ordering V190 must survive, so the second scenario per dialect drops `hzb_sop_schedule` after V180 and lets the migration create it. That is exactly the path that gave PostgreSQL `SMALLINT` and then broke on the script's own `SET enabled = FALSE`. Asserted on every combination: `NULL` and `' '` owners end disabled while `creator = 'alice'` stays enabled; `enabled` is a boolean in that dialect and `expr` is `CHARACTER LARGE OBJECT` / `LONGTEXT` / `TEXT`; a row seeded before the upgrade survives it and a 100 000 character `expr` round-trips after it; each required index exists exactly once, compared by column signature so a duplicate under a different name is caught; no stored routine is left behind; the history holds `190` once and none of `181/182/183`; a second startup applies nothing and validates clean. **Verified**, not just written: JDK 25 against real MySQL 8.4 and PostgreSQL 17 containers plus H2 2.2.224 — 10 tests green. Then mutation-checked by reverting each fix: | Reverted | Failure | |---|---| | `BOOLEAN`→`SMALLINT`, `FALSE`→`0` (PG) | `42804 column "enabled" is of type boolean but expression is of type integer` | | restore `CREATE INDEX idx_schedule_creator_conversation` (MySQL) | `42000 / 1061 Duplicate key name 'idx_schedule_creator_conversation'` | | drop the ownerless-schedule update (H2) | `a schedule without an owner must be disabled` | | recreate the Hibernate-owned index (H2) | `unexpected indexes … expected: <2> but was: <3>` | Two things running this against real servers turned up that reasoning alone had not. On MySQL, Hibernate declares the boolean as `bit(1)` while the migration's `BOOLEAN` lands as `tinyint(1)` — same values, two spellings — so the test accepts either there while pinning PostgreSQL to `bool`, which keeps the `SMALLINT` regression detectable. And MySQL Connector/J leaves `nullCatalogMeansCurrent` false, so an unqualified `DatabaseMetaData` lookup silently matched a same-named table in another test's database; the lookup is now pinned to the connection's catalog and schema. One dependency note, since it is the only build change: `mysql-connector-j` is added `test`-scoped to `hertzbeat-startup`, because it is `provided`-scoped in `hertzbeat-manager` and so never reaches the test classpath. The version comes from the root `dependencyManagement`, it is already a dependency of four other modules, and nothing `test`-scoped is packaged into the distribution. The PostgreSQL driver was already on that classpath, so it is not added. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
