-
Notifications
You must be signed in to change notification settings - Fork 1
Broaden search result for other sorting than "relevance" (resolves #10) #8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
This is relevant for search queries containing two words or more where the words are found in different product attributes. In this case, there is a mechanism in the search result which searches for the single words if no results are found otherwise. The mechanism was only used for search by relevance which is extended to other sort orders with this commit. Additionally, there was a bug in this mechanism - the parameter "mm=0%" has to be set for these additional requests.
Successfully tested in a client shop. |
$this->getQueryText(), | ||
0, | ||
$this->getPagination()->getPageSize() * $this->getPagination()->getCurrentPage(), | ||
$this->getParamsBuilder()->setBroaden($this->broaden)->buildAsArray($this->getAttributetoReset()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a conceptual difference between $broaden
and $attributesToReset
, that justifies passing one via setter and one via parameter to the build method? It looks confusing.
If no, I think, the setter is the better way, as it fits the builder pattern better:
- configure the builder
- build the object based on builder configuration
Then it could look like this:
$this->getParamsBuilder()
->setBroaden($this->broaden)
- ->buildAsArray($this->getAttributetoReset())
+ ->setAttributesToReset($this->getAttributetoReset())
+ ->buildAsArray()
This makes the interface more consistent as "setBroaden" is also implemented as a setter.
ResultsConfig $resultsConfig, | ||
AttributeRepository $attributeRepository, | ||
Pagination $pagination, | ||
ParamsBuilder $paramsBuilder, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be SearchParamsBuilder
now, because methods not in the interface are used (which is okay in this case, as discussed)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I changed this. See also integer-net/solr-pro#7 as I had to do changes to the pro library too due to changed interface.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't change it to SearchParamsBuilder
easily. It crashes with the Autosuggest.
@@ -70,7 +70,9 @@ public function build() | |||
$this->getQueryText(), | |||
0, | |||
$this->pagination->getPageSize() * $this->pagination->getCurrentPage(), | |||
$this->paramsBuilder->buildAsArray($this->attributetoReset) | |||
$this->paramsBuilder | |||
->setAttributeToReset($this->attributetoReset) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understood it correctly, setAttributesToReset
is only needed in one implementation. I think it should not be implemented in the abstract params builder and probably not even used in the abstract query builder then.
Here we can easily remove the line and move them to setAttributeToReset()
above:
public function setAttributeToReset($attributeToReset)
{
- $this->attributetoReset = $attributeToReset;
+ $this->paramsBuilder->setAttributeToReset($attributeToReset);
return $this;
}
Then move that method down to the class(es) where it is actually needed and we know that the type of paramsBuilder
supports it: SearchQueryBuilder
and CategoryQueryBuilder
(?)
This is relevant for search queries containing two words or more where
the words are found in different product attributes. In this case, there
is a mechanism in the search result which searches for the single words
if no results are found otherwise. The mechanism was only used for search
by relevance which is extended to other sort orders with this commit.
Additionally, there was a bug in this mechanism - the parameter "mm=0%"
has to be set for these additional requests.