Task: Model the geo ip2country store

Two hand-written files hold the whole feature. geo_ip2country_create.sql has the store, ores_geo_ip2country_tbl – ip_range int8range not null, tenant_id uuid not null, country_code text not null, no primary key, a GiST index on ip_range and a btree index on tenant_id – and the two functions ores_geo_inet_to_bigint_fn and ores_geo_ip2country_lookup_fn, which finds a country by ip_range @> address. dq_ip2country_artefact_create.sql has the staging table: dataset_id, tenant_id, range_start bigint, range_end bigint, country_code text, with a GiST index on the derived int8range(range_start, range_end + 1, '[)'). The publish function ores_dq_ip2country_publish_fn truncates the store and inserts the derived range. The artefact-type row names ip2country as the artefact type and geo_ip2country_tbl as its target. No pgTAP file covers either table.

ores.geo is a flat component – include/, src/, tests/, no api/core/service split – and it is not in the codegen component catalogue, so compass codegen regenerate --component geo refuses it before any model is read. Registering it is the first step either way.

The model can already state almost all of it. An * Artefact columns section carries range_start, range_end and country_code, and its key becomes the artefact's staging key. int8range passes through the templates as a column type: every column renders as {{name}} {{type}}, and the type check compares the model's type against the emitted one.

Two things are missing.

1. No index method. Both index faces render create index ... on "tbl" (columns), and neither can say using gist. The entity's index table takes name, columns, unique, current_only, where_extra and nulls_not_distinct, and the loader reads exactly those; the artefact's index drawer already forwards any property and the template simply does not render one. A using column on the entity index table plus a using clause in both templates is small and reusable.
2. A range column has no C++ type. A keyed entity gets a domain class, a repository and a protocol, and each needs a C++ type for every column. Nothing maps int8range, so an entity whose key or column is a range cannot render its client surface.

The second gap shapes the rest. Either

• (A) let a model state that it has no client surface, as a profile that withdraws the C++ and TypeScript facets the way artefact-staging-only withdraws the entity's own create script, keeping the store's ip_range int8range column exactly as it is; or
• (B) keep the range out of the model, storing it the way the staging table already does, as range_start and range_end bigints, and indexing the derived int8range(...) expression in both tables. The lookup predicate becomes that same expression, which PostgreSQL matches to the expression index, so containment lookups stay indexed.

Both keep the two functions working and both need the using change. (B) changes the store's columns and the lookup predicate; (A) leaves the SQL alone and adds a profile, which is more machinery but is also the shape every other SQL-only table will need.

compass check --only ctest caught what the non-heavy gate cannot: it runs no C++ suite, so the primary key this task added reached a consumer the gate does not see. ores.database.tests failed four unit_of_work_tests.cpp cases with duplicate key value violates unique constraint "ores_geo_ip2country_tbl_pkey". The suite uses ores_geo_ip2country_tbl as a generic probe, inserting '[1,2)' under a fresh random country_code per case to exercise rollback and visibility; the hand-written table was keyless and accepted that.

Settled by keeping the key and moving the probe. The key is honest – a range that appears twice is meaningless – and the suite wants a table of the right shape rather than this table. Each probe now draws its range from the same random source as its code, so no case can collide with another however many are added. The invalid-range probe keeps its literal: it is meant to fail.

ctest is 93 of 93 afterwards, and pgTAP 52 files.