[Port to dtq-dev] Issue dspace-customers#903: fix CLARIN table ownership for non-public schemas

[jr-rk]

Problem

Two CLARIN Flyway migrations hardcode the public. schema prefix in their ALTER TABLE … OWNER TO dspace statements, binding them to the public schema instead of the connection's search_path. Instances whose DSpace tables live in another schema do not get those objects assigned to the dspace role.

Port of dataquest-dev/dspace-customers#903 (item 5). Source: customer/vsb-tuo e2fb08358e.

Approach (changed after review)

The first revision edited V7.2_2022.07.28__Upgrade_to_Lindat_Clarin_schema.sql and V7.6_2024.08.05__Added_Preview_Tables.sql in place. That was reverted: both migrations are already applied, so changing their content changes their Flyway checksum, and DatabaseUtils.updateDatabase() — reached from Context.init() on every boot — would fail validation at the first Context on every existing install until a manual ./dspace database repair.

The fix is now a new forward migration; the two existing files are byte-identical to dtq-dev (verified: empty diff against the base commit). No checksum change, no repair step, no upgrade action for existing installs.

Change set

• Added V7.6_2026.09.11__Clarin_tables_owner_schema_agnostic.sql — a plpgsql DO block that reassigns the same 17 CLARIN and preview objects to dspace, resolving each unqualified name with to_regclass() so it matches against search_path instead of a hardcoded public..
• Reassignment is best-effort and idempotent. It is skipped when the dspace role does not exist, when the object is not present, when it is already owned by dspace, or when the statement lacks privileges (insufficient_privilege is trapped per object, leaving the current owner in place).

ALTER … OWNER TO also requires the target role to hold CREATE on the object's schema, not just role membership. That was an outright migration failure in the first draft of the script, found while testing against a tenant-owned schema, and is now one of the guarded cases.

The unrelated bitstore.xml hunk in the source commit (BitstreamStorageServiceImpl → SyncBitstreamStorageServiceImpl) remains excluded — a storage-bean swap unrelated to schema qualification, and dtq-dev already uses SyncBitstreamStorageServiceImpl.

Test evidence

PostgreSQL 15, throwaway container, script executed directly:

#	Scenario	Result
T1	non-public schema vsbtuo, dspace has no rights on it	4× NOTICE, exit 0, owners unchanged
T2	same + GRANT CREATE ON SCHEMA vsbtuo TO dspace	4 objects reassigned to dspace; same-named decoy public.license_definition untouched
T3	no dspace role in the cluster	NOTICE, exit 0
T4	rerun after T2	silent no-op
T5	database with no CLARIN tables	no-op, exit 0
T6	classic public-schema install, objects already owned by dspace	no-op, owners intact

T2 is the proof that resolution is schema-agnostic: only the search_path schema is touched.

Known limitation

A fresh install into a non-public schema still aborts inside V7.2 itself — ALTER TABLE public.license_definition OWNER TO dspace raises relation "public.license_definition" does not exist before any later migration runs, so this script is never reached there. Fixing that case would require editing V7.2, which is exactly what this revision avoids.

What this migration does cover: installs where V7.2 is already recorded (baseline or dump-restore into a non-public schema), and keeping the codebase schema-agnostic from here on.

Risk & rollback

Low. No DDL beyond object ownership, no schema or data change, no checksum impact on existing migrations. Rollback is dropping the new file — nothing to undo in already-migrated databases beyond ownership, which is restored with ALTER TABLE … OWNER TO <role>.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR updates two CLARIN-specific PostgreSQL Flyway migrations to avoid hardcoding the public. schema in ALTER TABLE … OWNER TO dspace statements, allowing the migrations to run correctly when DSpace tables live in a non-public schema (via the connection search_path).

Changes:

• Removed public. schema qualification from 14 ALTER TABLE … OWNER TO dspace statements in the Lindat/Clarin upgrade migration (V7.2).
• Removed public. schema qualification from 3 ALTER TABLE … OWNER TO dspace statements in the preview tables migration (V7.6).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
dspace-api/src/main/resources/org/dspace/storage/rdbms/sqlmigration/postgres/V7.2_2022.07.28__Upgrade_to_Lindat_Clarin_schema.sql	Drops public. qualifiers from ALTER TABLE … OWNER TO dspace so ownership changes resolve via search_path.
dspace-api/src/main/resources/org/dspace/storage/rdbms/sqlmigration/postgres/V7.6_2024.08.05__Added_Preview_Tables.sql	Drops public. qualifiers from ALTER TABLE … OWNER TO dspace for preview tables/sequences to support non-public schemas.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[milanmajchrak]

We cannot update already existing flyway scripts because there will be mismatch with the Flyway checksum. You need to create a new Flyway script.

[Copilot]

🔵 Needs a closer look

Object lookup must explicitly resolve the configured DSpace schema before approval.

Review details

Suppressed comments (2)

dspace-api/src/main/resources/org/dspace/storage/rdbms/sqlmigration/postgres/V7.6_2026.09.11__Clarin_tables_owner_schema_agnostic.sql:57

• This lookup is not limited to the DSpace schema. to_regclass searches the entire search_path, while Flyway is configured with the DataSource directly and does not apply DSpace's db.schema; a custom db.schema with the default public path will therefore match nothing, and search_path = tenant, public can fall through to a same-named public decoy when the tenant object is missing. Resolve against the configured/current DSpace schema explicitly (or configure Flyway's search path) before changing ownership.

        -- Unqualified to_regclass() resolves against search_path, so the object is found
        -- in whichever schema this install actually uses.
        object_oid := to_regclass(object_name);

dspace-api/src/main/resources/org/dspace/storage/rdbms/sqlmigration/postgres/V7.6_2026.09.11__Clarin_tables_owner_schema_agnostic.sql:14

• The comment says the migrations “issue” these ALTER statements, which is grammatically incorrect and makes the explanation unclear; “use” is intended here.

-- V7.6_2024.08.05__Added_Preview_Tables.sql issue `ALTER TABLE public.<name> OWNER TO

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Lite