Percolation issue

[im-denisenko]

Current Percolator implementation has a few problems:

• Missing support for count api.
• Missing explicit methods for query options (like setQuery, setAggregations, addAggregation, etc).
• Percolator requires Index in constructor, but actually there should be Type.
• Instance of Percolator can't be serialized to array and reused. This is blocker for https://github.com/ruflin/Elastica/issues/659.

My suggestions:

• Add new class Elastica\Percolate (equivalent of Elastica\Search).
• Add new class Elastica\Multi\Percolate (equivalent of Elastica\Multi\Search).
• Keep Elastica\Percolator for BC, but deprecate it in favor of classes above.

I would like to propose PR with these changes. Any thoughts?

[ruflin]

An alternative suggestion. Percolate has two steps:

• Register the query
• Match documents

It could make sense to separate the two. The query is stored as document on top of an index. So it makes sense to haven index for the "Percolator" object. The percolate function itself is the same as a query or search.

For me the Search object should be the single point of access for all "searchs" in the future. As Percolate is very similar, perhaps we should add it to the Search object instead of creating a new one.

So what we would end up with would be:

• Keep Percolator object but only to the registration of a query part
• Move percolate queries to the Search objects

[im-denisenko]

Keep Percolator object but only to the registration of a query part

Agreed.

Move percolate queries to the Search objects.

But why? Request to _search endpoint and request to _percolate endpoint may be similar in some particular points, but they differs so much, i don't sure they could be merged into one class. Maximum that we can do here is to move part of Elastica\Search class into traits and reuse them in Elastica\Percolate, am I miss something?

[ruflin]

The two functions we are talking about are matchDoc and matchExistingDoc. The use a completely different path but don't have any "real" complexity. I see it more from a conceptual point where I would look for these too functions. I would probably search for matchDoc in the Search object.

Probably the better option is to go with the Percolate object you suggested above and then either use a proxy inside search or go with traits. As so far with most of the time used proxy methods, I would suggest to use this.