Module conventions 

How the derives name what they generate, and which names they require of the structs they are placed on or link to.

Every naming rule goes through a Conventions implementation, chosen by the derive’s entry point (DefaultConventions for this project’s derives), so the rules can be swapped without touching a derive’s steps.

A derive never rebuilds another type’s generated type names from these rules: it links to the path the user wrote (see queryweave::Filterable), so each layer may name its types under different conventions. Generated member names (sort variants, filter fields) are different: a mirror (an API DTO) names the mirrored model’s members by applying its own conventions to the model’s field names, so the layers must agree on Conventions::sort_variant and Conventions::filter_field.

The conventions also say where the runtime crates the generated code names live (Conventions::core_crate, Conventions::api_crate, Conventions::sql_crate), so a crate that renames or re-exports them can still use the derives; #[queryweave(crate = path)] overrides them on a single struct. Each derive names exactly one runtime crate: the one of its layer (queryweave-api and queryweave-sql re-export the core).

Last, they list the integrations a Filters mirror may opt into (Conventions::integrations, see crate::integrations).

Structs

DefaultConventions

This project’s conventions.

FiltersNames

The names of the types #[derive(Filters)] generates for a struct (a domain model or a DTO).

Traits

Conventions

The naming rules of the derives.