Skip to content

Doc: Added missing instructions for schema upgrade from v4 to v5 in 1.7.0 doc #5437

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
MonkeyCanCode merged 5 commits into from
Sep 23, 2026
Merged

Doc: Added missing instructions for schema upgrade from v4 to v5 in 1.7.0 doc #5437

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
4bef113
Added missing instructions for schema upgrade from v4 to v5 in 1.7.0 doc
MonkeyCanCode Sep 3, 2026
b3348b6
Added missing instructions for schema upgrade from v4 to v5 in 1.7.0 doc
MonkeyCanCode Sep 6, 2026
57931e4
Added missing instructions for schema upgrade from v4 to v5 in 1.7.0 doc
MonkeyCanCode Sep 6, 2026
1efc1de
Fix sql
MonkeyCanCode Sep 14, 2026
bbd2909
Remove implicit cascade dependencies
MonkeyCanCode Sep 22, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions 1.7.0/metastores/relational-jdbc.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -122,6 +122,7 @@ that are not catalog-scoped. To upgrade an existing v3/v4 database, run the foll
CockroachDB, and H2), then restart Polaris:

```sql
DROP TABLE IF EXISTS polaris_schema.idempotency_records;

@dimas-b dimas-b Sep 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify my view on this: I'd prefer to use only this DROP TABLE statement for simplicity.

However, current three-statement SQL also looks correct to me.

@MonkeyCanCode MonkeyCanCode Sep 15, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO. We should keep the DROP TABLE only for this case as the other two will be auto drop in this case. Doesn't make much sense for an admin to run 2 extra commands that is not must needed. However, i think we need to consolidated with @adutra on his PR. The positive side with list out all changes is if an admin need to reverted, he/she will know what were removed...If he/she only do create table (without creating index/constraint), that would be incomplete revert (assuming we want to support revert?)

@flyingImer flyingImer Sep 22, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed on keeping only DROP TABLE here. These instructions cover v3/v4, but v3 has no idempotency_records table, so the new ALTER TABLE fails and stops the remaining migration statements with ON_ERROR_STOP enabled. The latest #5349 already uses only DROP TABLE IF EXISTS for this cleanup. Could we align this block with it so the cleanup works for both starting versions?

@MonkeyCanCode MonkeyCanCode Sep 22, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ML: https://lists.apache.org/thread/vpfq968ptnnr968ztb51w4tlo70mwqdn

ALTER TABLE polaris_schema.events ALTER COLUMN catalog_id DROP NOT NULL;
UPDATE polaris_schema.events SET catalog_id = NULL WHERE catalog_id = '__realm__';
UPDATE polaris_schema.version SET version_value = 5 WHERE version_key = 'version';
Expand Down