Field Collapsing Support #1653
Field Collapsing Support #1653
Conversation
There was a problem hiding this comment.
Thanks for the contribution, over LGTM. Also appreciate the details on why inheriting innerhits or going with abstract. I guess we can still change it later without breaking the API if we figure out the other path works better?
There are a few changes in this PR where I'm not sure if it's cleanup or related to the PR. If the addition of self etc. is not related, I think it's great to have it in but I would prefer to have it in a separate PR to separate the two and make the diff smaller.
| { | ||
| return $this->setParam('query', $query); | ||
| } | ||
|
|
||
| /** | ||
| * Gets the query object. | ||
| * | ||
| * @return \Elastica\Query\AbstractQuery | ||
| * @return array|\Elastica\Query\AbstractQuery |
There was a problem hiding this comment.
Where is this change coming from?
There was a problem hiding this comment.
Both Query::create and Query::__construct allow passing in an array as argument, which don't parse / convert this array into an ensemble of objects but keep it as-is, essentially leveraging the setRawQuery method.
Calling getQuery after taking the route above (or by just setting a raw query on the Query object) will return an array. I think that's something one should be aware of.
FWIW, I do like the option to set the raw query, however I'd rather have it in a way where it's not mingled with the usual query abstraction but has it's own representation to have better control over it during it's lifecycle.
lib/Elastica/Query.php
Outdated
| @@ -86,7 +91,7 @@ public static function create($query) | |||
| * | |||
| * @return $this | |||
| */ | |||
| public function setRawQuery(array $query) | |||
| public function setRawQuery(array $query): self | |||
There was a problem hiding this comment.
Cleanup. I'll remove them later today and re-add them in a new PR as you requested in your comment above.
Yes, that should work. Thing is that this might lead to a lot of duplicated code between both versions of InnerHits, on the flip side offering better control if they ever start to drift apart in ES DSL. I'd personally sit that out and wait how ES continues to handle field collapsing in the future, as this decision likely also depends on how complex collapsing becomes. |
That's going to be a bit awkward now: in the PR that added Field Collapsing Support (#1653) I forgot to check in the DSL classes, which made working with it a bit clumsy compared to the usual query methods. I.e. - as with aggregations - it's now possible to do stuff like this: ``` $collapse ->setFieldname('product_id') ->setInnerHits( $qb->collapse->inner_hits() // instead of (new Collapse\InnerHits()) ) ``` Let me know if there need to be any changes. Cheers :)
Added support for Field Collapsing as requested in #1392.
ES documentation: https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-body.html#request-body-search-collapse
Note: Inheriting
Query\InnerHitsinCollapse\InnerHitswas something I've been debating with myself over and over again. As far as I'm concerned it makes sense to have different classes, especially as the collapse one has to have support for the second level collapse, but I didn't want to duplicate the entire code for InnerHits.Downside is that right now there's no
AbstractCollapsebase-class as there is for the other concepts. Still feel like that's okay, because field collapsing is a quite simple concept right now.