Koha::REST::Plugin::Query
my ( $filtered_params, $reserved_params ) = $c->extract_reserved_params($params);
Generates the DBIC query from the query parameters.
$attributes = $c->dbic_merge_sorting({ attributes => $attributes, params => $params });
Generates the DBIC order_by attributes based on $params, and merges into $attributes.
$attributes = $c->dbic_merge_prefetch({ attributes => $attributes, result_set => $result_set });
Generates the DBIC prefetch attribute based on embedded relations, and merges into $attributes.
$attributes = $c->dbic_validate_operators( { filtered_params => $filtered_params } );
Validate operators in the passed query.
my $params = _build_query_params_from_api( $filtered_params, $reserved_params );
Builds the params for searching on DBIC based on the selected matching algorithm. Valid options are contains, starts_with, ends_with and exact. Default is contains. If other value is passed, a Koha::Exceptions::WrongParameter exception is raised.
$c->merge_q_params( $filtered_params, $q_params, $result_set );
Merges parameters from $q_params into $filtered_params.
$c->stash_embed( { spec => $op_spec } );
Unwraps and stashes the x-koha-embed headers for use later query construction
# Stash the overrides
$c->stash_overrides();
# Use it
my $overrides = $c->stash('koha.overrides');
if ( $overrides->{pickup_location} ) { ... }
This helper method parses the 'x-koha-override' headers and stashes the passed overrides in the form of a hashref for easy use in controller methods.
FIXME: With the currently used JSON::Validator version we use, it is not possible to use the validated and coerced data (it doesn't validate array-type headers) so this implementation relies on manual parsing. Look at the JSON::Validator changelog for reference: https://metacpan.org/changes/distribution/JSON-Validator#L14
# Stash the request ID
$c->stash_request_id();
# Use it
my $request_id = $c->stash('koha.request_id');
This helper method parses the 'x-koha-request-id' header and stashes the value.
my $reserved_words = _reserved_words();
my $order_atom = _build_order_atom( $string );
Parses $string and outputs data valid for using in SQL::Abstract order_by attribute according to the following rules:
string -> I<string>
+string -> I<{ -asc => string }>
-string -> I<{ -desc => string }>
my $embed = _parse_embed( $string );
Parses $string and outputs data valid for passing to the Kohaa::Object(s)->to_api method.
_merge_embed( $parsed_embed, $global_embed );
Merges the hash referenced by $parsed_embed into $global_embed.
my $source = _result_source( $result_set );
Returns the DBIC result source for $result_set. Handles both Koha::Objects (plural, via _resultset) and Koha::Object (singular, via _result).
my $added = _merge_count_select( $key, $attributes, $result_set );
Given a $key like claims_count (from a claims+count embed), strips the _count suffix to derive the DBIC relationship name, then uses the relationship metadata to build a correlated COUNT subquery added via +select/+as.
This makes the count available as a virtual column in the SQL result, enabling both server-side sorting (ORDER BY) and an efficient single-query count instead of N+1.
Returns the subquery scalar reference if added (used by the caller to substitute into ORDER BY clauses), or undef if the relationship was not found in the prefetch_whitelist or has no DBIC relationship info. In the latter case, the count embed still works for display: to_api falls back transparently to the original $object->$relation->count Perl-level call. Only sorting is unavailable.
Handles both Koha::Objects (plural, via _resultset) and Koha::Object (singular, via _result) for accessing the DBIC result source.
my $subquery = _build_count_subquery( $rel, $result_set, $parent_alias, $main_source );
Builds a correlated COUNT subquery scalar ref for the given DBIC relationship. $parent_alias is the SQL alias of the parent table (e.g. me for top-level, or the relation name for nested embeds like biblio).
$main_source is the DBIC ResultSource of the top-level result set (the one aliased as me). It is used for nested embeds to resolve the FK chain back to me, avoiding references to join aliases that may not be available inside DBIC's limiting subquery when pagination and has_many prefetches are combined.
This FK-chain resolution only covers ONE level of nesting: $parent_alias must be a direct relationship of $main_source (true for every +count embed currently declared in api/v1/swagger/, e.g. biblio.items+count). If that assumption doesn't hold - $parent_alias is itself a nested alias, its relationship condition isn't a plain hashref (e.g. a coderef custom join), or no matching column is found - we decline to build the subquery and return undef, rather than emit SQL that may reference an unavailable alias. The caller then falls back to its normal "no DBIC relationship" degradation path (prefetching the association directly, so to_api uses the Perl-level $object->$relation->count call, and the sort fixup rejects a sort attempt with a clean 400 instead of a 500).
Returns the scalar ref, or undef if the relationship has no DBIC metadata or the correlation cannot be safely resolved.
my $prefetch = _parse_prefetch( $key, $embed, $result_set, $attributes, $parent_alias, $count_aliases, $main_source );
Recursively builds the DBIC prefetch structure for a given embed key. Handles nested +count embeds by injecting correlated COUNT subqueries via _build_count_subquery.
my $dbic_param = _from_api_param( $key, $result_set );
Translates a dot-separated API parameter name into its DBIC equivalent using the result set's from_api_mapping.
my $query = _parse_dbic_query( $q_params, $result_set );
Recursively translates API query parameters into DBIC-compatible query structures, resolving dot-separated paths into nested relationship queries.