Database schema changes for `PersistentIdentityService` are now problematic because existing custom data migration scripts for relevant tables (and their tests) depend on the `PersistentIdentityService`.
Say, you want to change `PersistentIdentityService` tables schema from V1 to V2. Hence, existing custom migration scripts will perform migration against V1, however they will depend on PersistentIdentityService functionality with V2.
`PersistentIdentityMigration` from `node-core.changelog-v12.xml` - the script itself is good but its test should be adapted
`IdentityServiceToStringShortMigrationTest.kt` - implicitly performs Node schema migration to the latest version (before testing actual migration), so it will fail if `PersistentIdentityService` schema will change
`PersistentIdentityMigrationNewTable` from `node-core.changelog-v14-data.xml` - uses `CordaMigration` which depend on `PersistentIdentityService` and other services with the latest schema. This script is also permanently "sticking" to the end of the changelog due to `CordaMigration` dependency.
`PersistentIdentityMigrationNewTableTest` - depends on `PersistentIdentityService` and ... what does it test? definitely not the migration itself.
To make both mentioned scripts independent from PersistentIdentityService by copying relevant table schema version into test space
Move `node-core.changelog-v14-data.xml` in top direction in changelog (close to its historical position) to avoid confusion when creating new patches. At the moment this patch is on different positions in OS and ENT, so we need to synch anyway.
There is a `vault-schema.changelog-v9.xml` with custom `VaultStateMigration` script which is also "sticking" at the end of `node-core.changelog-master.xml`. This may be also problematic, because every new patch has to be inserted before it and, hence, may potentially affect `VaultStateMigration` execution. We may need to consider further changes of `CordaMigration` to break dependencies on the latest services/schemas.