https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30818 --- Comment #1 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- [2022/05/20 09:10:31] [ERROR] GET /api/v1/biblios: unhandled exception (DBIx::Class::Exception)<<DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Unknown column 'xx1' in 'where clause' at /usr/share/perl5/Data/Page.pm line 50>> Koha::REST::Plugin::Exceptions::__ANON__ /usr/share/koha/Koha/REST/Plugin/Exceptions.pm (73) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30818 --- Comment #3 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Marcel de Rooy from comment #2)

The REST API is a great thing. But I must admit that going thru all these modules, plugins, etc. the exact meaning of a lot of subroutines is unclear and the comments are sparse. Hoping that not only Tomas has a global detailed view of what is going on here.. ;)

There are two main things that need to be considered when thinking about the API tooling: 1. We need to map attributes from the API to the actual DB names. This happens when creating/updating resources, as well as querying. The latter is the most complex in the code (i.e. the recursive _parse_dbic_query) 2. When we are using q= in conjunction with x-koha-embed, we need to prefetch/join the right tables. This is mainly handled by _parse_prefetch. About (1). In the original implementations, the controllers had two methods: to_model and to_api. So the mappings were entirely handled there. The problem with that is the fact we wanted to do more complex things like embedding related objects, so the API representation of an object needed to be handled on the object itself. There's some redundancy, most probably in the attributes_from_api and friends stuff on the Koha::Object(s) method. That could be polished. But the main thing is it needs to be handled at that level and reused as much as possible. There are not many more things to optimize there IMHO. About (2). This is the difficult part. Embeds can happen at an arbitrary depth. Like in 'x-koha-embed: biblio.items.checkouts.patron'. As the 'how I should be rendered on the API' question is answered at the Koha::Object level, we build a data structure ('embed' param for to_api) that contains a (probably enhanceable) data structure representing the 'rest of the tree' that each object needs to embed. Along with this data structure, there's the need to build the prefetches/joins so we optimize things. Embedding can happen on real 'relations' (thus actual prefetches take place) or just on 'methods output' in which case no prefetch takes place. This is handled by _parse_prefetch, which is also recursive. Regarding to_api(), we are adding new parameters that are passed through to related objects like 'public'. So each object, needs to know how it should render on an unprivileged context. So, TL;DR Our helper methods take care of handling what the OpenAPI plugin generates out of the requests, and convert it into: - Queries, objects, etc with mapped attribute names - Prefetches are appended to resultsets with embeds - Generate data structure to be passed to to_api() And most of the magic takes place in Koha::Object->to_api(). The most complex bit is querying. Regarding this bug, I believe the solution is to catch the DBIx::Class::Exception in the objects.search helper, and return a 400 with a meaningful message. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30818 NAYEMA NASRIN <nayema@mes.ac.in> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nayema@mes.ac.in -- You are receiving this mail because: You are watching all bug changes.