Debugging queries
This page summarizes general steps and ideas for debugging TypeDB queries.
Locating errors
When your query returns an error, the TypeDB server will report a stack trace of error messages; you will find the most relevant message on the top of that trace.
-
In the case of a syntax error, the error message will indicate the line and character position where the error occurred.
-
In other cases, the error message should give an indication of which logical conflicts caused the error in the database. A natural debugging approach is to isolate the part of the query that you believe caused that conflict, and then make the necessary changes before returning to your larger query.
-
Unexpected pipeline result. When a query results in an unexpected output or data write, the simplest way to debug the query is to take advantage of TypeQL’s compositional nature. Simply remove query clauses to inspect intermediate query operations when debugging a pipeline.
-
Unexpected clause result. To debug an individual clause, again you can take advantage of TypeQL’s compositional nature. Split the clause into smaller clauses and execute them one by one to see their results, pinpointing the part that misbehaves.
Dissecting stages
In complex pipelines, it is often useful to truncate your query to specific stages. This allows you to inspect “intermediate results”. You can output results for specific variables of those stages using the select operator. It is also often useful to simply output the number of results of (a part of) your pipeline via the reduce operator:
... # incoming pipeline
reduce $c = count; # outputs answer count of incoming pipelineLimiting queries
If query executes indefinitely and does not return results, a sanity check that it can potentially produce at least one result in a reasonable time is always a good idea:
... # incoming pipeline
limit 1; # stops the execution after consuming one answerNew issues
Send us a message on Discord!