Created attachment 135072 [details] [review] Bug 30790: Add REST API route to list biblios Examples: GET /api/v1/biblios GET /api/v1/biblios?q={"me.title": "foo"} GET /api/v1/biblios?q={"biblioitem.isbn": "1-23-456789-0"} GET /api/v1/biblios?_order_by=title Test plan: 1. Try requesting this endpoint with your favorite API tool 2. Run `prove t/db_dependent/api/v1/biblios/list.t`
We have hidden the biblioitem table from the API. I regret not having spent time on a more generic solution yet... Take a look at... Orders.pm when it comes to filtering by biblio.*
(In reply to Tomás Cohen Arazi from comment #2) > We have hidden the biblioitem table from the API. I regret not having spent > time on a more generic solution yet... > > Take a look at... Orders.pm when it comes to filtering by biblio.* It looks like Koha/REST/Plugin/Objects.pm was duplicated inside Koha::REST::V1::Orders::list ... is it what we are supposed to do ? :/
(In reply to Julian Maurice from comment #3) > (In reply to Tomás Cohen Arazi from comment #2) > > We have hidden the biblioitem table from the API. I regret not having spent > > time on a more generic solution yet... > > > > Take a look at... Orders.pm when it comes to filtering by biblio.* > > It looks like Koha/REST/Plugin/Objects.pm was duplicated inside > Koha::REST::V1::Orders::list > ... is it what we are supposed to do ? :/ No, that's why I say I regret not finding the time to provide a generic solution... Namely, a pair of Koha::Objects methods for tweaking the 'embed' structure and queries....
(In reply to Tomás Cohen Arazi from comment #4) > No, that's why I say I regret not finding the time to provide a generic > solution... Namely, a pair of Koha::Objects methods for tweaking the 'embed' > structure and queries.... I just noticed that I can do GET /api/v1/biblios?q={"isbn": "1-23-456789-0"} without the "biblioitem." prefix and it works too. So... is there something else needed ? (except updating the tests and commit messages to reflect that)
Created attachment 135089 [details] [review] Bug 30790: Add REST API route to list biblios Examples: GET /api/v1/biblios GET /api/v1/biblios?q={"title": "foo"} GET /api/v1/biblios?q={"isbn": "1-23-456789-0"} GET /api/v1/biblios?_order_by=title Test plan: 1. Try requesting this endpoint with your favorite API tool 2. Run `prove t/db_dependent/api/v1/biblios/list.t`
Created attachment 135199 [details] [review] Bug 30790: Add REST API route to list biblios Examples: GET /api/v1/biblios GET /api/v1/biblios?q={"title": "foo"} GET /api/v1/biblios?q={"isbn": "1-23-456789-0"} GET /api/v1/biblios?_order_by=title Test plan: 1. Try requesting this endpoint with your favorite API tool 2. Run `prove t/db_dependent/api/v1/biblios/list.t` Signed-off-by: David Nind <david@davidnind.com>
+ $schema->resultset('Biblio')->delete(); Hmm
my $biblios_rs = Koha::Biblios->new->search(undef, { join => 'biblioitem' }); Not a normal pattern to use new here
(In reply to Marcel de Rooy from comment #8) > + $schema->resultset('Biblio')->delete(); > > Hmm What is wrong with this ? It's in the tests, inside a transaction. (In reply to Marcel de Rooy from comment #9) > my $biblios_rs = Koha::Biblios->new->search(undef, { join => 'biblioitem' }); > > Not a normal pattern to use new here Bad copy/paste/edit here ... I'll fix it
(In reply to Julian Maurice from comment #10) > (In reply to Marcel de Rooy from comment #8) > > + $schema->resultset('Biblio')->delete(); > What is wrong with this ? It's in the tests, inside a transaction. We try to avoid direct DBIx stuff when having an Koha object. Yes, this may be faster. But Koha objects abstract the DBIx. So here you could simply do Koha::Biblios->delete. Like: t/db_dependent/HoldsQueue.t: Koha::Biblios->delete(); But found: t/db_dependent/Koha/BiblioUtils/Iterator.t:$schema->resultset('Biblio')->delete();
Just trying to get a bit more grip on what could be done with the query string: objects.search my $args = $c->validation->output; [..] my ( $filtered_params, $reserved_params, $path_params ) = $c->extract_reserved_params($args); Query extract_reserved_params $c->req->params->to_hash is compared with $c->validation->output The first iiuc is all get/post parameters. But what exactly is the second? Where is this output method exactly? Thus far couldnt find it yet in the JSON Validator and OpenAPI stuff..
Seeing this too: # Failed test 'No tests run for subtest "get() tests"' # at t/db_dependent/api/v1/biblios/list.t line 89. DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Cannot delete or update a parent row: a foreign key constraint fails (`koha_myclone`.`issues`, CONSTRAINT `issues_ibfk_2` FOREIGN KEY (`itemnumber`) REFERENCES `items` (`itemnumber`) ON UPDATE CASCADE) at t/db_dependent/api/v1/biblios/list.t line 48
(In reply to Marcel de Rooy from comment #13) > Seeing this too: > > # Failed test 'No tests run for subtest "get() tests"' > # at t/db_dependent/api/v1/biblios/list.t line 89. > DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st > execute failed: Cannot delete or update a parent row: a foreign key > constraint fails (`koha_myclone`.`issues`, CONSTRAINT `issues_ibfk_2` > FOREIGN KEY (`itemnumber`) REFERENCES `items` (`itemnumber`) ON UPDATE > CASCADE) at t/db_dependent/api/v1/biblios/list.t line 48 Yes, when you delete biblios there could still be issues !
(In reply to Marcel de Rooy from comment #14) > (In reply to Marcel de Rooy from comment #13) > > Seeing this too: > > > > # Failed test 'No tests run for subtest "get() tests"' > > # at t/db_dependent/api/v1/biblios/list.t line 89. > > DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st > > execute failed: Cannot delete or update a parent row: a foreign key > > constraint fails (`koha_myclone`.`issues`, CONSTRAINT `issues_ibfk_2` > > FOREIGN KEY (`itemnumber`) REFERENCES `items` (`itemnumber`) ON UPDATE > > CASCADE) at t/db_dependent/api/v1/biblios/list.t line 48 > > Yes, when you delete biblios there could still be issues ! You might better consider adding a few biblios without deleting them all btw. And adjusting your queries based on that situation?
Picking bug 32734 which includes more use cases (response formats based on the Accept header) and is pretty similar and active. *** This bug has been marked as a duplicate of bug 32734 ***