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. Each relation also gets a Boolean existence variant — <rel>Exists for forward FKs (posts: {authorExists: true}), <rel>Exist for reverse (users: {postsByAuthorIdExist: false}) — compiling to a bare (NOT) EXISTS over the join.
• relational ordering: one-level orderBy over related rows, named REL__COLUMN_{ASC,DESC} with a double underscore separating relation and column (posts: orderBy: [AUTHOR__NAME_ASC]). Forward FKs sort by the referenced parent row's column via a correlated scalar subquery; reverse FKs aggregate the referencing rows' column (MIN for ASC, MAX for DESC). The related columns respect the filters.indexed_only policy exactly like the table's own orderBy values. Toggled via plugins.settings.advanced-filters.relation_order (also off when relations is off).
• 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.