case 3977
This commit is contained in:
@@ -11,24 +11,7 @@
|
||||
|
||||
## ROUGH SCHEDULE TO GET TO BETA
|
||||
|
||||
|
||||
|
||||
search bug(s):
|
||||
new or possibly always there bug besides mqt thing:
|
||||
search for "007m1qt *nd" matches only two of the three 007m1qt records when it should be three and the *nd matches a bunch of other shit with no 007m1qt in it
|
||||
in v7 there were similar weirdnesses I've noticed when using wildcards mixed with non wildcards or multiple wildcards it can return records without all teh search terms
|
||||
What I expect to happen is records that contain all the search terms only will be returned
|
||||
I'm thinking of rewriting it all as a direct raw sql query as it's tortuous with the complex ef queries required and they don't quite make sense and my tentative semi fix involved just a stab in the dark without fully seeing why it was required
|
||||
then I can troubleshoot and refine entirely in sql and also match more the v7 query cycle which is much simpler
|
||||
maybe all in a stored procedure / view or something?
|
||||
then I could just call the view from ef and it would be ready to roll
|
||||
Make it happen properly.
|
||||
TODO: Each term should narrow down the results to only include those items with *all* the matches in them only regardless of use of wildcards or anything else.
|
||||
prototype it in pgadmin as a single query / view until it works with the combos we need then make it solid and recode that shit
|
||||
|
||||
This query illustrates the problem perfectly: *1QT* *44*
|
||||
which should return exactly one result but returns 12, a bunch of 44's and a few qt's but not AND, rather OR
|
||||
|
||||
|
||||
Testing cases
|
||||
|
||||
Update front / back
|
||||
@@ -782,6 +765,6 @@ BUILD 133 CHANGES OF NOTE
|
||||
- case 3996
|
||||
- case 3999 see note
|
||||
- case 4001
|
||||
- case 3977
|
||||
- case 3977 fixed
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user