advancedfilters

Overview ¶

Package advancedfilters is a built-in plugin extending the generated filter/orderBy surface with two features default generation leaves out:

• relation filters: filter a table by conditions on related rows — a forward FK exposes the parent's filter directly (posts: {author: {mood: {eq: HAPPY}}}), a reverse FK exposes a {some|none|every} wrapper over the child's filter (users: {postsByAuthorId: {some: {published: {eq: true}}}}). Both compile to EXISTS subqueries inside the single statement.
• computed-column filtering and ordering: stable/immutable row-type functions without extra arguments become filter fields and orderBy enum values (postCount: {gt: "5"}, orderBy: [POST_COUNT_DESC]), compiled as function calls over the current row.

The plugin only adds schema surface plus catalog bindings; the compiler reads the bindings from schema.Built and stays inert when they are absent, so disabling the plugin (plugins.disabled: [advanced-filters]) removes the feature completely. The two halves toggle independently via plugins.settings.advanced-filters.{relations,computed}.

The surface is also tunable per object through smart comments (parsed directly from catalog comments, so this works even when the smart-comments plugin is disabled):

• "@omit filter" on a foreign key skips its relation filter (both directions); "@omit filter" / "@omit order" on a computed function skips its filter field / orderBy values.
• with plugins.settings.advanced-filters.relations_opt_in (or computed_opt_in) set, the default flips: only foreign keys / computed functions tagged "@filterable" (alias "@sortable") get filter surface.
• "@fieldName" / "@foreignFieldName" renames apply automatically (they flow through the shared inflection pipeline).

Note: computed columns are not covered by indexes (unless a matching expression index exists), so computed filter/order fields bypass the filters.indexed_only policy by nature.