40 fix schema translate map rel class

[nicoloesch]

Depends on AustralianCancerDataNetwork/omop-alchemy#57. Requires pyproject.toml version update for oa-configurator, orm-loader, and omop-alchemy

Summary

• Fixes omop-graph relationship-classification load command does not honour non-default schema #40

Root cause

• relationship-classification was writing outside the configured CDM schema
  • a stale DROP TYPE no-op plus unqualified staging-table SQL.
• The OAK-lib adapter (OMOPAlchemyImplementation) resolved a database URL but discarded its
  schema_translate_map, silently ignoring the configured schema for all ontology/concept
  traversal, not just this one command.
• omop_resource()/ OMOPAlchemyImplementation never wired a configured split vocabulary connection through to a real second engine at all
  • KnowledgeGraph silently collapsed to one connection whenever a caller, including every production path, omitted vocab_engine explicitly.

Fix

• relationship-classification now respects the configured CDM schema end to end
• The OAK-lib adapter carries its schema_translate_map through to the engine it builds, and skips engine construction entirely when a caller injects kg= directly.
• omop_resource() now builds both the primary and vocabulary engines via oa-configurator's create_engines(), and OMOPAlchemyImplementation accepts and forwards a real vocab_engine
  • a genuinely separate vocabulary connection is now supported end to end in production

Checklist

• Applied exactly one label (breaking, feature, fix, dependencies, or chore)
• Tests pass locally (uv run pytest -q): 46 passed
• Lint passes (uv run ruff check .)

[gkennos]

This PR relies on the new schema/connection contracts in oa-configurator, omop-alchemy, and orm-loader, but the current dependency ranges still accept older 1.x releases that do not provide the complete updated contract. It also declares omop-emb>=2,<3, while omop-emb PR #57 is labelled as breaking and may need to ship as v3; in that case this extra would exclude the required release.

Before merge, please choose the five package versions, raise the downstream minimums to the first compatible releases, update the lockfile, and add one composed job that installs those exact versions (or the five exact heads until publication). That job should cover SQLite, same-server/multi-schema PostgreSQL, a genuinely separate vocabulary connection, and the optional embedding extras from a clean environment.

[gkennos]

KnowledgeGraph.__init__ requires non-empty RelationshipMapping data on the primary connection, but this command is the supported way to create that data and it refuses to run when vocab_connection is genuinely separate. The suggested manual provisioning without the FK leaves end users without an end-to-end initialisation path.

Could classification remain graph-owned on the primary connection and, for split deployments, either omit the cross-database FK or validate relationship IDs against the vocabulary connection in application code before inserting? A regression test should start from a fresh primary database plus a separate vocabulary database, run the documented command, and then successfully construct KnowledgeGraph. Same-connection deployments can retain the FK.

[gkennos]

_relationship_mapping_lookup(session) performs an unfiltered q_relationship_mapping_all() here on every split-mode edges() call, even though the constructor has already loaded the same data into self._relationship_mapping. Traversal-heavy consumers call this path repeatedly, so the split topology adds a full primary-database query and materialisation per node/step.

Please reuse the cached mapping, or query only the relationship IDs present in vocab_rows. If the mapping needs runtime refresh, make that an explicit cache-invalidation operation rather than silently re-reading it on this one path.