[Koha-bugs] [Bug 27034] $c->objects->search shouldn't use path parameters

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27034

David Nind <david at davidnind.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #114777|0                           |1
        is obsolete|                            |

--- Comment #9 from David Nind <david at davidnind.com> ---
Created attachment 115796
  -->
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=115796&action=edit
Bug 27034: Do not use path parameters on building the query

This patch simply removes the use of path parameters on building the
query in $c->objects->search.

The sample usage in the original tests considers a specific use case in
which the 'nested' resultset has the path param in its attributes:

GET /patrons/:patron_id/holds

In this case, $c->objects->search would be passed a Koha::Holds
resultset into which it would build a query. As the patron_id param can
be mapped into a Koha::Hold attribute, this works.

We don't actually use this approach in code. What we do is searching for
the patron, and properly return a 404 if the patron doesn't exist [1]. If it
exists, we actually call $patron->holds to get the related resultset, so
there's no gain in having the path param on the query afterwards.

That said, if we wanted to build:

GET /holds/:hold_id/pickup_locations

as the latter is a calculated value, from a resultset that doesn't
actually include a (mapped to some attribute) hold_id attribute, there's
no way to use it if it will automatically add the hold_id to the
pickup_locations resultset. It will give errors about hold_id not being
an attribute of Koha::Library (Branches.pm actually).

So this patch removes the automatic use of path parameters in
$c->objects->search. We can extract them in the controller and add them
to the passed resultset if required. But this patch removes a constraint
we have for building routes controllers right now.

[1] If we didn't return the 404, and we just passed a fresh Koha::Holds
resultset to be feeded with the patron_id, we would always return an
empty array in cases where the patron doesn't exist. This would be
misleading, but I'm open to discuss it. Design-wise.

Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>

Signed-off-by: David Nind <david at davidnind.com>

-- 
You are receiving this mail because:
You are watching all bug changes.