Keep SQL and Go in step

Add checks for the SQL, generated output and application behaviour. You will also introduce two mistakes to see which check catches each one.

Starting point

Continue after testing, with the rollback test passing.

Step 1: Run the checks locally

../sgl config validate
../sgl vet --strict
../sgl fmt --check
../sgl generate --check
go test .

The commands check configuration, SQL diagnostics, directive formatting, generated output and runtime behaviour in that order. A passing generation check means the files on disk match the current input.

Step 2: Observe a source error

In ListTasks, replace its projection with:

SELECT id, missing_title, completed FROM tasks ORDER BY id;

../sgl vet --strict

The diagnostic names the unknown column:

missing_title

Read its file location and code. ../sgl explain CODE gives the diagnostic's meaning, with CODE replaced by the reported value.

Restore the projection:

SELECT id, title, completed FROM tasks ORDER BY id;

Step 3: Observe stale output

Rename the query directive, leaving the generated code untouched:

-- sgl.query(ListAllTasks, many)

../sgl generate --check

The command reports that the generated files need updating. Restore the name so the existing caller still builds:

-- sgl.query(ListTasks, many)

../sgl vet --strict
../sgl generate --check
go test .

Step 4: Transfer the checks to CI

Put the first command block in your application's CI job, with the job's working directory set to the module containing sgl.yaml. In an application that pins Seagull as a module tool, use go tool sgl in place of ../sgl.

You now have a tested local data layer. Continue with PostgreSQL and pgx or embedding the generator.