Fixes #29493: expand entity_extension.extension from VARCHAR(256) to VARCHAR(512)

[ivnvMkhl]

Description of Changes

Fixes #29493

FullyQualifiedName.buildHash builds the extension key by MD5-hashing each FQN segment and joining with dots. For deeply nested columns (8+ levels) this produces keys longer than 256 chars (8 segments × 32 chars + 7 dots = 263), exceeding the entity_extension.extension column limit and causing a DB error:

value too long for type character varying(256)

This PR expands the column to VARCHAR(512), which safely covers up to 15 nesting levels (15×32 + 14 = 494 chars).

Changes:

• Migration 2.0.3 for PostgreSQL and MySQL
• Bootstrap schemas (postgres.sql, mysql.sql) updated to match

Type of Change

• Bug fix

High-level Design

N/A — schema-only change, no logic changes.

Testing Coverage

• Manual testing: reproduced the overflow with a table containing 8-level nested struct columns, confirmed the migration resolves the error.

UI Evidence

Not applicable.

Checklist

• Read the CONTRIBUTING documentation
• Title follows Fixes #<issue>: <description> format
• PR linked to issue entity_extension.extension VARCHAR(256) overflow for deeply nested columns (8+ levels) #29493
• Migration scripts updated for schema change

---

Summary by Gitar

• Migration management:
  • Relocated the entity_extension.extension column expansion from a standalone 2.0.3 migration into the existing 2.0.0 schemaChanges.sql files for both MySQL and PostgreSQL.

_{This will update automatically on new commits.}

Greptile Summary

This PR expands the entity_extension.extension column from VARCHAR(256) to VARCHAR(512) in both MySQL and PostgreSQL to fix an overflow caused by deeply nested struct columns. FullyQualifiedName.buildHash produces MD5-hash-per-segment keys, and 8+ nesting levels exceed 256 characters.

• The fix is applied to the 2.0.0 migration schemaChanges.sql for both databases, consistent with the team's pattern of consolidating pre-release migrations (2.0.1 was previously merged into 2.0.0 via chore(migrations): move 2.0.1 migrations into 2.0.0 #29391).
• Bootstrap schema files (mysql.sql, postgres.sql) are updated to match, keeping fresh installs consistent with migrated ones.
• The migration comment explains the VARCHAR(512) bound and documents why TEXT was not chosen (PK constraint in MySQL).

Confidence Score: 5/5

Safe to merge — schema-only change expanding a column width with no logic alterations.

The change is narrowly scoped: four files, all touching the same column definition. Both the migration and the bootstrap schema are updated consistently. The MySQL migration correctly preserves charset (ascii_bin) and NOT NULL. The PostgreSQL ALTER COLUMN TYPE form preserves the NOT NULL constraint implicitly. The combined PK byte footprint (36 + 512 = 548 bytes ASCII) is well within InnoDB's 3072-byte index limit. Placing the fix in the 2.0.0 migration is consistent with this repo's established pattern of consolidating pre-release migrations.

No files require special attention.

Important Files Changed

Filename	Overview
bootstrap/sql/migrations/native/2.0.0/mysql/schemaChanges.sql	Appends ALTER TABLE to expand extension VARCHAR(256→512) with correct charset/collation preservation and NOT NULL constraint.
bootstrap/sql/migrations/native/2.0.0/postgres/schemaChanges.sql	Appends ALTER TABLE to expand extension VARCHAR(256→512); NOT NULL is preserved separately by PostgreSQL's ALTER COLUMN TYPE semantics.
bootstrap/sql/schema/mysql.sql	Bootstrap schema updated to VARCHAR(512) for entity_extension.extension, keeping fresh installs consistent with migrated deployments.
bootstrap/sql/schema/postgres.sql	Bootstrap schema updated to VARCHAR(512) for entity_extension.extension, consistent with MySQL schema and migration.

_{Reviews (6): Last reviewed commit: "Rewords Postgres migration comment to be..." | Re-trigger Greptile}

[github-actions]

❌ PR checklist incomplete

This PR cannot be merged until the following are addressed on its linked issue:

• Linked issue entity_extension.extension VARCHAR(256) overflow for deeply nested columns (8+ levels) #29493 is not added to the Shipping project.

The fields live on the linked issue in the Shipping project (open the issue → right sidebar → Projects). After you set them, re-run this check (or push a commit) — issue/project changes do not re-trigger it automatically.

Maintainers can bypass this check by adding the skip-pr-checks label.

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[TeddyCr]

Thanks for your contribution @ivnvMkhl. This won't solve the underlying issue. It simply move the bound higher up. If we are seeing this kind of error in production let's solve the root cause

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[github-actions]

🔴 Playwright Results — 4 pipeline/setup failure(s)

✅ 0 passed · ❌ 0 failed · 🟡 0 flaky · ⏭️ 0 skipped

Pipeline and setup failures

• The build job finished with status failure.
• Shard detection finished with status failure.
• The Playwright shard matrix was unexpectedly skipped.
• No expected Playwright shards were declared.

Shard	Passed	Failed	Flaky	Skipped

📦 Download artifacts

How to debug locally

# Download playwright-test-results-<shard> artifact and unzip
npx playwright show-trace path/to/trace.zip    # view trace

[ivnvMkhl]

Thanks for the quick feedback, @TeddyCr — fair concern, and I looked into it before writing the width bump.

Why buildHash grows linearly: FullyQualifiedName.buildHash MD5-hashes each FQN segment individually and joins them with . (rather than hashing the whole FQN once). That's not incidental — several places rely on the resulting hash preserving the segment structure for prefix lookups, e.g. CollectionDAO.getExtensions/getExtensionsByPrefixBatch (WHERE extension LIKE CONCAT(:prefix, '.%')) and tag inheritance for nested columns in Entity.populateEntityFieldTags via tag_usage.targetFQNHash. Replacing it with a single fixed-length hash per FQN would break those prefix queries and require re-hashing every existing row in entity_extension and tag_usage in production — a live-data migration, not a code-only change.

This repo already has precedent for handling this the way I proposed. When FQN-hash columns were introduced in 1.1.0, most of them were sized well above 256 for exactly this reason:

-- 1.1.0/postgres/schemaChanges.sql
ALTER TABLE tag_usage ADD COLUMN tagFQNHash VARCHAR(382), ADD COLUMN targetFQNHash VARCHAR(382);
ALTER TABLE field_relationship ADD COLUMN fromFQNHash VARCHAR(382), ADD COLUMN toFQNHash VARCHAR(382);
ALTER TABLE web_analytic_event ... ADD COLUMN fqnHash VARCHAR(768);

entity_extension.extension is the one hash column that was left at 256 and never revisited, which is why it's the one that overflows first on deeply nested columns.

Given that, I'd suggest: merge the width bump now (zero migration risk, brings this column in line with its siblings, unblocks the overflow users are hitting today), and I'm happy to open a separate issue to scope a real redesign of buildHash (e.g. bounding growth without losing prefix-search semantics) if the team wants to pursue that — but that touches shared hashing infra used by tags/lineage too and deserves its own design discussion rather than riding along on this bug-fix PR. Let me know if you'd like me to open that issue now.

[harshach]

@ivnvMkhl lets add the change 2.0.0 migrations not 2.0.3

[ivnvMkhl]

@harshach Moved the schema change into the 2.0.0 migration (mysql + postgres), removed the standalone 2.0.3 folder.

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[ivnvMkhl]

@gitar-bot Good catch — reworded the comment (pushed 45d26a3). It now states the real reason VARCHAR(512) is used here: Postgres itself has no restriction on TEXT in a btree primary key, but the column is kept as VARCHAR(512) to stay identical to the MySQL migration, where TEXT can't be a PK component without a prefix index.

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[gitar-bot]

Code Review ✅ Approved 1 resolved / 1 findings

Expands the entity_extension.extension column to VARCHAR(512) to prevent overflow on deeply nested FQNs, with migration statements correctly integrated into the 2.0.0 schema updates. No issues found.

✅ 1 resolved

✅ Quality: MySQL-specific comment copied into Postgres migration

📄 bootstrap/sql/migrations/native/2.0.0/postgres/schemaChanges.sql:468-469
The PostgreSQL migration comment states "MySQL cannot use a TEXT column as a PK component without a prefix index" — a MySQL-specific rationale that is out of place in a Postgres file (Postgres has no such restriction). Remove or reword the comment to a Postgres-relevant note to avoid confusing future maintainers.

Options

Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}