check-queries: cross-check GeoPackage-sourced layer queries against the gpkg schema #155

New issue

Open

opened 2026-08-17 22:00:50 +00:00 by art-bot · 0 comments

art-bot commented

2026-08-17 22:00:50 +00:00

Collaborator

check-queries (#98, PR #148) has two halves, and between them they leave one
gap: a layer query that reads a source GeoPackage is checked by neither.

The PREPARE half only reaches the destination database, so a gpkg-sourced query
is skipped by design. The static half only covers downloads whose URL carries a
WFS PROPERTYNAME= list, and a GeoPackage has no such URL. Measured across the
five configs, 17 of 74 queries skip for this reason — and they are not a
scattering, they are most of Iceland:

ismap   8 skipped: roads, water_bodies, waterways, contours, peaks,
                   buildings, airports, water_points
semap   5 skipped
fimap   4 skipped
plmap   0
world   0

That is the majority of Iceland's map, and it is exactly the place a #79-style
bug would hide: a query naming a column its source does not provide, invisible
locally because nothing connects the two.

What would close it

The same shape as the PROPERTYNAME half, against a different contract. The
GeoPackage is on disk at check time and importer/gpkg.go already reads its
schema, so:

For each layer source entry whose db: resolves to a file path, open the
GeoPackage and read the column set of the layer(s) it declares.
Run the existing scanQuerySQL qualified-reference scan over the query.
Report a reference to a column the GeoPackage does not have, exactly as
propertyNameViolation does today.

The scanner, the alias attribution and the violation reporting all exist — this
is a second source of "columns this table is guaranteed to have", not new
machinery. Same limitation applies: unqualified column names can't be
attributed to a table without a full parser.

Why it is not in #148

#148's two halves are each complete against their own contract, and this is a
third contract with its own file-format work. Filing rather than widening that
PR. Noted in docs/importer-cli.md so the gap is documented where the command is.

`check-queries` (#98, PR #148) has two halves, and between them they leave one gap: a layer query that reads a **source GeoPackage** is checked by neither. The PREPARE half only reaches the destination database, so a gpkg-sourced query is skipped by design. The static half only covers downloads whose URL carries a WFS `PROPERTYNAME=` list, and a GeoPackage has no such URL. Measured across the five configs, 17 of 74 queries skip for this reason — and they are not a scattering, they are most of Iceland: ``` ismap 8 skipped: roads, water_bodies, waterways, contours, peaks, buildings, airports, water_points semap 5 skipped fimap 4 skipped plmap 0 world 0 ``` That is the majority of Iceland's map, and it is exactly the place a #79-style bug would hide: a query naming a column its source does not provide, invisible locally because nothing connects the two. ## What would close it The same shape as the PROPERTYNAME half, against a different contract. The GeoPackage is on disk at check time and `importer/gpkg.go` already reads its schema, so: 1. For each layer source entry whose `db:` resolves to a file path, open the GeoPackage and read the column set of the layer(s) it declares. 2. Run the existing `scanQuerySQL` qualified-reference scan over the query. 3. Report a reference to a column the GeoPackage does not have, exactly as `propertyNameViolation` does today. The scanner, the alias attribution and the violation reporting all exist — this is a second source of "columns this table is guaranteed to have", not new machinery. Same limitation applies: unqualified column names can't be attributed to a table without a full parser. ## Why it is not in #148 #148's two halves are each complete against their own contract, and this is a third contract with its own file-format work. Filing rather than widening that PR. Noted in `docs/importer-cli.md` so the gap is documented where the command is.

art-bot referenced this issue from a commit

2026-08-17 22:03:16 +00:00

#98 review: unique PREPARE names, honest advice when nothing was checked, and #155 for the gpkg gap