Closed dan-langridge closed 1 month ago
@dan-langridge That's interesting, what level of fuzziness would you like? Is there an algorithm that you are already using with the current app?
@dan-langridge Thanks for the details!
@dan-langridge I have done some preliminary investigation into this, and here is what I have found:
On the parcels page, we only fetch the parcels from that database that will be displayed i.e. if we have some filters and have 20 as the number of parcels on the page, we only fetch 20 parcels with those filters applied at the database level.
Now, this set-up requires us to bake this fuzzy search functionality into the query, or use the database's native fuzzy search functionality to look for parcels. However, incorporating this isn't yet supported by the backend service unfortunately.
One alternative we could adopt for now would be to search for multiple texts using the original search query, with some minimum number of letters for a match. For example, if we had "Benjamin" as the search text and have 3 as the minimum number of letters to match, we could have "ben", "enj", "nja", jam", "ami" and "min" as possible matches and look for parcels. If the search text is "James Bond" then we could search for "jam", "ame", "mes", "bon" and "ond", taking into account the white space.
This isn't ideal or clever in any sense, but may give you what you need. What do you think?
Is this only an issue for the Parcels page? Or the Clients page too?
Although a good hack, does’t sound like the best solution for now so happy put this on the back burner until it’s fully supported by the backend
On 27 Mar 2024, at 16:10, Ricky Kawagishi @.***> wrote:
@dan-langridge https://github.com/dan-langridge I have done some preliminary investigation into this, and here is what I have found:
Background
On the parcels page, we only fetch the parcels from that database that will be displayed i.e. if we have some filters and have 20 as the number of parcels on the page, we only fetch 20 parcels with those filters applied at the database level.
Now, this set-up requires us to bake this fuzzy search functionality into the query, or use the database's native fuzzy search functionality to look for parcels. However, incorporating this isn't yet supported by the backend service unfortunately.
Alternative
One alternative we could adopt for now would be to search for multiple texts using the original search query, with some minimum number of letters for a match. For example, if we had "Benjamin" as the search text and have 3 as the minimum number of letters to match, we could have "ben", "enj", "nja", jam", "ami" and "min" as possible matches and look for parcels. If the search text is "James Bond" then we could search for "jam", "ame", "mes", "bon" and "ond", taking into account the white space.
This isn't ideal or clever in any sense, but may give you what you need. What do you think?
— Reply to this email directly, view it on GitHub https://github.com/NorwoodAndBrixtonFoodbank/nbf-website/issues/207#issuecomment-2023161200, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATD4UHTK2ET2NMCLVY6EMWDY2LOO3AVCNFSM6AAAAABFJMIP3OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRTGE3DCMRQGA. You are receiving this because you were mentioned.
Is this only an issue for the Parcels page? Or the Clients page too? Although a good hack, does’t sound like the best solution for now so happy put this on the back burner until it’s fully supported by the backend
@dan-langridge I expect we could technically make use of the database fuzzy search on the Clients page with a fair amount of work - although we would face the same issue if we ever want to add more filters into the Clients page. Putting this off for now sounds like a good idea to me personally.
Is your feature request related to a problem? If so, please describe.
No response
Describe the solution / feature you'd like
When I search a name, the search should be "Fuzzy"
If I search Daniel, also show Dan If I search Benjamin, also show Ben
This is the only search box we want to be fuzzy. Postcode, phone number etc should be exact.
Additional context
No response