Bug #33700
Invalid behavior of search for integer in Backend search
Status: | Resolved | Start date: | 2012-02-06 | |
---|---|---|---|---|
Priority: | Should have | Due date: | ||
Assigned To: | - | % Done: | 100% |
|
Category: | Default | Spent time: | - | |
Target version: | - | |||
TYPO3 Version: | 4.6 | Is Regression: | ||
PHP Version: | 5.3 | Sprint Focus: | ||
Complexity: | medium |
Description
Backend search (and Live search once #31761 has been merged) do not behave as stated in the 4.6 Release notes (http://wiki.typo3.org/TYPO3_4.6#Live_Search):
In previous TYPO3 versions, there were several problems with Backend search:
- ...
- it searched "uid" and other numeric fields even if the value was not numeric
- it used LIKE x search on numeric fields
- ...
In fact current implementation does not replace the LIKE operator with an SQL equal statement for numeric fields but whenever a query that can be interpreted as integer is encountered, regardless of the underlying column type.
Example: If you have pages "102 W", "102 E", you used to be able to search for "102" and get them, but now the query is casted to an integer and the page title is search for an equality on "102" resulting in an empty result list.
The underlying column type should be used instead (code to cache this information is already available within DBAL and Helmut started months ago to backport it to Core itself: #28654).
Related issues
Associated revisions
[BUGFIX] Invalid behavior of search for integer in Backend search
In fact current implementation does not replace the LIKE
operator with an SQL equal statement for numeric fields
but whenever a query that can be interpreted as integer
is encountered, regardless of the underlying column type.
Example: If you have pages "102 W", "102 E", you used
to be able to search for "102" and get them, but now
the query is casted to an integer and the page title
is search for an equality on "102" resulting in
an empty result list.
The underlying column type should be used
instead (code to cache this information is already
available within DBAL and Helmut started months
ago to backport it to Core itself: #28654).
Thanks to Clio Online for sponsoring this fix!
Resolves: #33700
Releases: 6.0, 4.7, 4.6
Change-Id: I8c4cceac5320b9135ccf9e99892cc57dcfffadc5
Reviewed-on: http://review.typo3.org/13990
Reviewed-by: Mattias Nilsson
Tested-by: Mattias Nilsson
Reviewed-by: Felix Kopp
Tested-by: Felix Kopp
Reviewed-by: Dmitry Dulepov
Tested-by: Dmitry Dulepov
[BUGFIX] Invalid behavior of search for integer in Backend search
In fact current implementation does not replace the LIKE
operator with an SQL equal statement for numeric fields
but whenever a query that can be interpreted as integer
is encountered, regardless of the underlying column type.
Example: If you have pages "102 W", "102 E", you used
to be able to search for "102" and get them, but now
the query is casted to an integer and the page title
is search for an equality on "102" resulting in
an empty result list.
The underlying column type should be used
instead (code to cache this information is already
available within DBAL and Helmut started months
ago to backport it to Core itself: #28654).
Thanks to Clio Online for sponsoring this fix!
Change-Id: Iadc7e3e454d14b2b5012fd02324089600200d8f4
Resolves: #33700
Releases: 6.0, 4.7, 4.6
Reviewed-on: http://review.typo3.org/16479
Reviewed-by: Marco Bresch
Tested-by: Marco Bresch
Reviewed-by: Soren Malling
Tested-by: Soren Malling
Reviewed-by: Dmitry Dulepov
Tested-by: Dmitry Dulepov
[BUGFIX] Invalid behavior of search for integer in Backend search
In fact current implementation does not replace the LIKE
operator with an SQL equal statement for numeric fields
but whenever a query that can be interpreted as integer
is encountered, regardless of the underlying column type.
Example: If you have pages "102 W", "102 E", you used
to be able to search for "102" and get them, but now
the query is casted to an integer and the page title
is search for an equality on "102" resulting in
an empty result list.
The underlying column type should be used
instead (code to cache this information is already
available within DBAL and Helmut started months
ago to backport it to Core itself: #28654).
Thanks to Clio Online for sponsoring this fix!
Change-Id: I527b2eb742f663985866e717fcf572f2a7e33574
Resolves: #33700
Releases: 6.0, 4.7, 4.6
Reviewed-on: http://review.typo3.org/16477
Reviewed-by: Marco Bresch
Tested-by: Marco Bresch
Reviewed-by: Soren Malling
Tested-by: Soren Malling
Reviewed-by: Dmitry Dulepov
Tested-by: Dmitry Dulepov
History
#1 Updated by Francois Suter over 3 years ago
- File issue33700.diff
added
Xavier, here's a patch for this issue. I'm not sure what you meant about the caching stuff, but it doesn't seem to be committed yet, but the bug still needs to be fixed. Therefore I wanted your opinion before pushing this patch for review.
#2 Updated by Francois Suter over 3 years ago
NOTE: this patch is only for live search, if you agree with it, I'll adapt it for BE search too.
#3 Updated by Dmitri Pisarev about 3 years ago
Why isn't this patch commited yet, not even in 4.7?
I have a table with date field that I used to search with strings as '20120510' and now it just does not work. This search ability is crucial to my site editors.
Had to temporary fix it by hand.
Please commit! And also in BE search.
#4 Updated by Felix Kopp about 3 years ago
I don't know if this patch also solves this problem:
string fields containing just numbers will not be found via live search.
Example:
If page title '112' can not be found via live search.
Search interpretes input as int and does not look into string fields, right?
#5 Updated by Marco Bresch about 3 years ago
Hi all,
tested this patch successfully in live search. My testcase was to search a zipcode in feusers. Without the patch the feuser was not found and with the patch the feuser was found.
Greetings
Marco :-)
#6 Updated by Mads Jensen almost 3 years ago
The patch really needs to be committed for both live search and regular BE search. For us, searching in BE is, unfortunately, pretty much useless as is.
For some reason I'm not able to fix it by XCLASSing (modified classes are not loaded), and with no hooks, I'm left with modifying the core directly.
EDIT: We're currently using TYPO3 v4.7.2
Regards
Mads
#7 Updated by Gerrit Code Review almost 3 years ago
- Status changed from New to Under Review
Patch set 2 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13990
#8 Updated by Gerrit Code Review almost 3 years ago
Patch set 3 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13990
#9 Updated by Gerrit Code Review almost 3 years ago
Patch set 4 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13990
#10 Updated by Gerrit Code Review over 2 years ago
Patch set 5 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13990
#11 Updated by Gerrit Code Review over 2 years ago
Patch set 6 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/13990
#12 Updated by Soren Malling over 2 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 7e443bd4362dd9d40188a04caefadfb005ac6be1.
#13 Updated by Gerrit Code Review over 2 years ago
- Status changed from Resolved to Under Review
Patch set 1 for branch TYPO3_4-7 has been pushed to the review server.
It is available at http://review.typo3.org/16476
#14 Updated by Gerrit Code Review over 2 years ago
Patch set 1 for branch TYPO3_4-7 has been pushed to the review server.
It is available at http://review.typo3.org/16477
#15 Updated by Gerrit Code Review over 2 years ago
Patch set 1 for branch TYPO3_4-6 has been pushed to the review server.
It is available at http://review.typo3.org/16479
#16 Updated by Soren Malling over 2 years ago
- Status changed from Under Review to Resolved
Applied in changeset 7c02b0c232f4a7244c7a08e391ef450a12e01e80.