- Ya
- 25 Agosti 2026, 14:26 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 3ecbbac
ddl-auto built PRIMARY KEY (logical_id, resource_type, tenant_id) on fhir_resource_current and fhir_resource_version, because Hibernate emits @EmbeddedId columns alphabetically rather than in declaration order. On YugabyteDB the FIRST primary-key column decides the hash shard, so leading with a UUID distributes one practice's entire chart across every tablet and turns each read into a cross-node fan-out — the exact opposite of why the composite key exists. Recreates rather than ALTERs: changing a primary key is a table rewrite and Yugabyte's ALTER ... ADD PRIMARY KEY support is limited. Both tables are new and empty so this is exact and cheap, and the runner REFUSES to touch a table holding rows — at that point the right move is a planned migration with a data copy, and finding that out from a log line beats finding it out from missing charts. Idempotent, and it verifies against pg_constraint rather than assuming: once the key is right it inspects, agrees and does nothing. Exceptions are caught per table, because a throw escaping a runner silently withholds every runner ordered after it.