REST API : ApiInformationObjectsBrowseAction - getting all facets and counts in API response
James Grimster
I am wondering if anyone has approached this?
At the moment, the results array in the REST API response to a query creates arrays of place_access_points , creators based on the current resultSet , i.e. paged / skip.
If you have 1000 Total Hits , paged on 10 at a time, would informationobjectsBrowseAction.class.php be the place to modify, so that the facets and counts for ALL 1000 total hits are returned in the JSON API response?
Or, have I got the wrong end of the stick and this is controlled from somewhere else?
I think the underlying ElasticSearch supports it, because that must be what the main site informationobject/browse is doing? So, is it an adjustment to the query in arRestApiPlugin/modules/api/actions/informationobjectsBrowseAction.class.php
I ask, because we want to create a separately hosted interface, which includes the facet filtering.
Thank you
Best wishes,
--
James Grimster
Orangeleaf Systems Ltd
Johan Pieterse
Hi James,
Half right, I think. That is the file to change, but the two arrays you are looking at are not facets, so widening them will not get you what you want.
In informationobjectsBrowseAction.class.php, place_access_points and creators are built inside the foreach over the result set, one entry per hit, from that record's own $doc['places'] and $doc['creators']. They are per-record field values, not counts. They are scoped to the page because they describe the ten records on the page, and there is nothing there to widen.
The reason you see no facet counts is simpler: the action never asks for any. It runs the search and returns ['total' => $resultSet->getTotalHits(), 'results' => $results], and that is the whole payload. Worth saying too that the two booleans in getQuery(false, true) are $allowEmpty and $filterDrafts, so that is not a facet switch you can flip.
You are right that the engine supports what you want. Aggregations are computed over the entire matching set and are unaffected by from/size, so you can have counts for all 1000 hits while still returning 10 records.
The site browse does it in DefaultBrowseAction, apps/qubit/modules/default/actions/browseAction.class.php. It checks for an AGGS property, calls $this->search->addAggs($this::$AGGS) and $this->search->addAggFilters($this::$AGGS, $this->getParameters) before searching, then reads $resultSet->getAggregations() afterwards. The AGGS definition itself sits at the top of apps/qubit/modules/informationobject/actions/browseAction.class.php, and it is just an array of field/type/size entries you can lift straight across.
So the change in the REST action is to add the aggs to the query before the search call and read getAggregations() into the JSON. Three things that will bite otherwise:
Aggregations come back keyed on term ids, not names. places.id, creators.id, repository.id and so on. The site resolves those separately when it populates the facet labels, so without the same lookup your interface will show numbers.
Each AGGS entry has size => 10, so you get ten buckets per facet and no more. Raise it for your use, and keep in mind terms aggregations are approximate once cardinality gets high.
addAggFilters is what makes the counts respect the filters already applied, which is normally what people expect from facets. Skip it and the counts describe the unfiltered query.
One last thing, since this is going to a public interface: keep filterDrafts on. Aggregations respect the query they are attached to, so if drafts are not filtered out your counts will quietly include unpublished records even though the results do not.
Regards
--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ica-atom-users/53674CD1-2212-46A5-9236-374EB1604B8C%40orangeleaf.com.
082 337-1406
James Grimster
To view this discussion visit https://groups.google.com/d/msgid/ica-atom-users/CAA4s_cB9LVkU2Bg8cZjqf%2BxMwz5XCmfrCMPp96sLs1zwEX_HkQ%40mail.gmail.com.
James Grimster
Orangeleaf Systems Ltd
www.orangeleaf.com
--
Privacy and Confidentiality Notice
The information contained in this email message is intended only for the named person, firm or company to whom it is addressed. Such information may be confidential and privileged and no mistake in transmission is intended to waive or compromise any such privilege. If you have received it in error please destroy it and notify us on the address shown.
Registered in England No. 3648762 | VAT 709 2483 28