You started with a fresh checkout, set up PostgreSQL with example data, ran the example app under mvn quarkus:dev, queried customers directly, traversed a @reference to Address, and ran INSERT and UPDATE mutations against film. The directives you used (@table, @field, @reference, @lookupKey, @mutation) cover the common case; everything else builds on the same idea: GraphQL types map to PostgreSQL tables, and directives pick the SQL shape.

This page lists the four how-to recipes most worth reading next, then points at the rest of the manual.

Recipes most relevant after this tutorial

The four topics below are the ones to read next. The how-to landing lists every available recipe.

Add custom conditions

The active filter you used on page 3 is the simplest case of an argument-driven WHERE. The @condition directive lets you wire arbitrary jOOQ predicates onto fields and arguments: WHERE rental_rate < ?, WHERE title ILIKE ?, conjunctive filters across multiple input fields, anything jOOQ can express. How-to: Add custom conditions walks through the Java method shape and the three placement axes; How-to: Stacking and overriding conditions covers the override flag and the divergence from legacy semantics.

Pagination and sorting

The customers query you ran returns all five rows. Real schemas paginate: Graphitron supports both Relay-style cursor pagination (@asConnection, first/after) and dynamic ordering (@orderBy, @order). How-to: Cursor-paginated connections walks through turning a list field into a connection; How-to: Sort results covers tie-breakers, @defaultOrder, and keyset semantics.

Error handling

The mutations on page 5 happily commit anything that PostgreSQL accepts. Real mutations need to surface validation errors (constraint violations, business-rule failures) as typed GraphQL errors, not opaque exceptions. How-to: The errors channel covers union vs single-type carriers, the cause-chain dispatch loop, and the redact-with-correlation-id fallback.

Test your schema

The example module’s own tests under src/test/java/…​/querydb/ are the recommended pattern for pinning your schema’s behaviour against a real PostgreSQL. How-to: Test your schema walks through copying that pattern into your own project: how to wire Graphitron.newExecutionInput(dsl, …​) against Testcontainers, how to assert on response shapes, and how to use the QUERY_COUNT/SQL_LOG listeners to ratchet round-trip counts.

Where the rest of the manual sits

How-to guides

The full task-indexed list. Beyond the four recipes above, the chapter covers @service for hand-written fetchers, @lookupKey for batched key lookups, @splitQuery for opt-in DataLoader batching, polymorphic types via @discriminate and unions, Apollo Federation, custom scalars, tenant scoping, and global node identification.

Reference

Authoritative descriptions of every directive, every Maven plugin parameter, and every diagnostic the validator emits. Use this when you know the directive name and want the parameter list and constraints; use the how-to chapter when you know the task and want a recipe.

Explanation

The design decisions behind Graphitron: why the database catalog is the source of truth, why @condition methods take a table parameter, why authorization stays in PostgreSQL row-level security, how the batching model works. Read this chapter when "why does it work this way" matters more than "how do I use it".

You have finished

The tutorial is over. The example you built against is the same one the rest of the manual references in its verified by pointers; if a how-to or reference page mentions a query, you can paste it into the same curl shape from page 3 and run it against your local server.

← Previous: A first mutation

↑ Tutorial overview