-
Notifications
You must be signed in to change notification settings - Fork 203
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
Fix EZP-27416: Error 500 on search when trying to search space or single quote #2029
Conversation
Will you also reuse |
@andrerom Fixed :-) |
|
||
$wordIdSubquery = $this->getWordIdSubquery($subSelect, $criterion->value); | ||
if ($wordIdSubquery === null) { | ||
return $query->expr->neq(1, 1); |
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.
This is still not compatible with declared return type, and I think it's require few words of comment .
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.
This is still not compatible with declared return type, and I think it's require few words of comment .
I looked over returned values in other criterions and I actually think that @return
in getWordIdSubquery
PhpDoc is just wrong - it should be @return string
because all methods of the eZ\Publish\Core\Persistence\Database\Expression
interface return string as well.
Updated with PostgreSQL compatible version. |
I gave it a little bit of thought and I think we should consider two separate cases here, applied on SQL Search layer, so not affecting other search engines:
if (trim($query->query->value) === '') {
return new SearchResult(['time' => 0, 'totalCount' => 0]);
} because search for an empty value should always return 0 count in 0 time (other
WDYT @andrerom ? |
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.
Some minor comments below:
array('searchQuery' => ''), | ||
array('searchQuery' => '\''), | ||
array('searchQuery' => ' '), | ||
); |
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.
Nitpick: please use short array syntax.
* | ||
* @dataProvider getFullTextQueriesWithoutWords | ||
*/ | ||
public function testFullTextOnQueryWithoutWords($searchQuery) |
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.
Please hint also @param
in PhpDoc
$contentService->publishVersion( | ||
$contentService->createContent( | ||
$contentCreateStruct, | ||
array($locationService->newLocationCreateStruct(2)) |
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.
Nitpick: please use short array syntax.
$query = new Query( | ||
array( | ||
'query' => new Criterion\FullText($searchQuery), | ||
) |
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.
Nitpick: please use short array syntax.
|
||
$wordIdSubquery = $this->getWordIdSubquery($subSelect, $criterion->value); | ||
if ($wordIdSubquery === null) { | ||
return $query->expr->neq(1, 1); |
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.
This is still not compatible with declared return type, and I think it's require few words of comment .
I looked over returned values in other criterions and I actually think that @return
in getWordIdSubquery
PhpDoc is just wrong - it should be @return string
because all methods of the eZ\Publish\Core\Persistence\Database\Expression
interface return string as well.
@adamwojs I kind of likes part of the proposal, but I had and have doubts about hardcoding logic about full text in the handler, as value can be anything here right? |
@adamwojs: @andrerom has a good point here, I looked at this from the FullText Criterion perspective, not the whole scope of all possible Criterions - my mistake. To determine if the value is correct should be a responsibility of @andrerom can we expect from API consumer not to allow such queries or be prepared for this exception? |
I was thinking in similar way, adding exception that we handle internally, however how do we then tell UI to tell the user the query was invalid and this is why there is empty result? |
True. So I'd say the only one valid solution is to throw |
…in valid token in Legacy Search Engine
57d1ddc
to
39d37e8
Compare
I've updated PR according to our consensus about solution |
39d37e8
to
6d864c9
Compare
6d864c9
to
c1c11a6
Compare
*/ | ||
protected function getWordIdSubquery(SelectQuery $query, $string) | ||
{ | ||
$subQuery = $query->subSelect(); | ||
$tokens = $this->tokenizeString( | ||
$this->processor->transform($string, $this->configuration['commands']) | ||
); | ||
|
||
if (empty($tokens)) { | ||
throw new InvalidArgumentException('string', 'Search query does not contains any searchable token'); |
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 rather be something that actually is 1. concrete enoug so devs know what is wrong, 2. user friendly enough so user knows what he did wrong.
Unsure, but something like :
Search query does not contain a valid FullText search string
Would also be great if we can create a new exception that extends InvalidArgumentException, so UI code can detect it better in case they want to provide a better user feedback then this.
@@ -178,14 +178,21 @@ protected function getWordExpression(SelectQuery $query, $token) | |||
* @param \eZ\Publish\Core\Persistence\Database\SelectQuery $query | |||
* @param string $string | |||
* | |||
* @return \eZ\Publish\Core\Persistence\Database\SelectQuery | |||
* @return \eZ\Publish\Core\Persistence\Database\SelectQuery|null |
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.
when does it return null? On exceptions nothing is returned at all ;)
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.
*Also note that handle()
should add phpdoc that it uses getWordIdSubquery
so the throw part gets reflected there to.
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.
Think this is better, some nitpicks added
…t contain valid token in Legacy Search Engine
@@ -0,0 +1,21 @@ | |||
<?php | |||
|
|||
namespace eZ\Publish\Core\Search\Common\Exception; |
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'm not sure about namespace, but for me is too specific for \eZ\Publish\Core\Base\Exceptions
and too generic for concrete search engine impl.
/** | ||
* Exception thrown FullText search string is invalid. | ||
*/ | ||
class InvalidFullTextSearchString extends InvalidArgumentException |
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.
Maybe InvalidFullTextQuery will be better a name ?
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'd say either keep it as is or InvalidFullTextSearchQuery
.
Side thing: if we intend for external bundle to be able to catch it (and thus refer to it), shouldn't it be a part of API, not Core? Or maybe SPI to avoid cluttering API namespace? POV @andrerom?
…t contain valid token in Legacy Search Engine
Closing PR as obsolete. eZ Platform 2.5 has reached EOM, so please reopen PR in ezsystems/ezplatform-kernel (bug fixes) or ibexa/core (features/improvements) if issue is still valid for v3.3 / v4.x and you are willing to work on it. |
Description
This PR provide patch to incorrect generated SQL in Legacy Search Engine when user is trying to search a query that contains only a word separators characters e.g single quote character.
Steps to reproduce
'
(single quote)TODO