On this page

Troubleshoot generation and execution

Start with sgl vet and the first diagnostic's source location. Fix the SQL or configuration before investigating errors from executing generated code.

Read a diagnostic

sgl vet --strict
sgl explain Q027

Replace Q027 with the code vet reports. For example, a misspelt directive keyword gives a location and a suggested correction:

broken/db/queries/tasks.sql:2:31: error[Q027]: unknown keyword argument "optinal" on sgl.param
   |
 2 | -- :title as sgl.param(title, optinal: true)
   |                               ^^^^^^^
help: did you mean "optional"?

Correct optinal to optional and run vet again. Errors exit 1. Warnings exit 0 unless --strict is set; hints do not fail vet.

A tool that embeds the generator reads the same explanation from the root package, seagull.sh/seagull: seagull.LookupCode("Q027") returns what sgl explain prints, and seagull.Codes() lists every code.

Find a missing generated method

Check the generation command's exit status and diagnostics. If a query has an error, the CLI leaves that query out, writes the rest of the package and exits 1. A migration, schema or package-name error stops output for the whole database.

Fix the reported problem, regenerate and compile the caller:

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

The diagnostics example shows both a warning and partial generation. The diagnostics reference explains every code.

Investigate a runtime failure

If analysis passes but a query fails when called, check the actual driver, connection and applied schema. Verify the parameter values and inspect the returned driver error. Constraints, permissions and cancellation are checked by the database at execution time.

For a changed schema, use schema inspection. For a missing row or NULL value, check the generated query contract. For a custom value that will not scan or bind, check type overrides.

Examples for this page