-
Notifications
You must be signed in to change notification settings - Fork 24
Description
With this new client, everything is based on running scrolls, as opposed to grabbing a certain sized query. Caching is based on URL+POST information. However, with ElasticSearch scrolls, the exact same URL is used to acquire different results. Thus, trying to cache the page results in an infinite loop of the same results. (I know; I tried. This is how I figured out how scrolling worked...)
Caching is critical to Dist::Zilla::Role::MetaCPANInterfacer, since the queries would be ran on just about every 'dzil' command.
I have a potential solution, but I wanted your opinion of it first. It uses the fact that MetaCPAN::Client::ResultSet->scroller needs a Search::Elasticsearch::Scroll object. I created something called Search::Elasticsearch::FakeScroll, which acts like a scroll, but doesn't actually use the scroll function. Instead, it would be called with a reduced size parameter, and puts the all of the results in the same kind of result set that Scroll would use.
In fact, there isn't much to the code:
package Search::Elasticsearch::FakeScroll;
use Moo;
use namespace::clean;
extends 'Search::Elasticsearch::Scroll';
#===================================
sub BUILDARGS {
#===================================
my ( $class, $params ) = parse_params(@_);
delete $params->{scroll};
delete $params->{scroll_in_body};
my $es = delete $params->{es};
my $results = $es->search($params);
return {
es => $es,
aggregations => $results->{aggregations},
facets => $results->{facets},
suggest => $results->{suggest},
took => $results->{took},
total_took => $results->{took},
total => $results->{hits}{total},
max_score => $results->{hits}{max_score},
_buffer => $results->{hits}{hits},
is_finished => 1,
};
}
1;
Then MetaCPAN::Client would have some sort of switch to enable this mode (passed to MetaCPAN::Client::Request), so that caching doesn't loop.