btlqql commented on PR #1374: URL: https://github.com/apache/rocketmq-dashboard/pull/1374#issuecomment-5351992303
I investigated the reported conflict against the actual PR base, `rocketmq-studio` (the bot's `origin/develop` example does not match this PR). The textual conflicts themselves are straightforward, but the base branch has changed substantially since the last review: commits such as `6fd7657`, `5854515`, `bff8ce1`, `7443227`, `e6c2a7f`, and `9fced5f` standardized numeric auto-increment keys, renamed several persistence tables, and added authentication/session schema. As a result, simply rebasing would leave both the V1 baseline and V2 existing-volume migration behind current trunk. It could pass the current build while producing an unusable upgraded database. Before I push a destructive migration strategy, could a maintainer confirm the intended compatibility boundary? 1. Should Flyway migrate databases from the pre-`6fd7657` string-ID schema all the way to current `rocketmq-studio`, preserving existing rows across the key and table-name conversion? 2. Or is it acceptable to regenerate the baseline from current trunk and support only databases already using the standardized numeric-key schema? I have the conflict resolution prepared locally and will update the migration/tests based on the confirmed upgrade boundary. -- 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]
