Contributors mailing list archives
Re: Special way of searching for productsby
Open for Small Business, Graeme Gellatly
I've done this for years in one way or another. OCA does have trgm module which allows similarity search but for most use cases I find mostly the issue is one of order of search terms. Product search is particularly sucky because it has all sorts of overrides.
This is in general my simple approach.
1. Install pg_trgm or else you will feel the pain.
2. Override search and split the name argument into multiple ilikes. In my case I typically split on spaces, which means users can search "Red Car" or "Car Red" and get same result. I do it on spaces only.
I know you want to avoid but actually for your use case you are better just copying the way bank accounts are sanitized and searched. Stored computed sanitized code, then sanitize search args on way in. Trigram index that stored field
On Thu, Apr 29, 2021 at 9:42 AM Pierre Verkest <email@example.com> wrote:
Few ideas based on postgresql:* not sure if it's possible with SIMILAR TO or ~ operators* investigate extension* fuzzystrmatch: https://www.postgresql.org/docs/13/fuzzystrmatch.html* create your own unaccent rules: https://www.postgresql.org/docs/current/unaccent.htmlregards,Le mer. 28 avr. 2021 à 22:33, Radovan Skolnik <firstname.lastname@example.org> a écrit :Hello, I have been asked few times by users if it is possible to search for products in a way omitting special characters (like dash or space for exmaple) from product's default_code (or even input string). Let me give an example: Let's say we have a product with default_code like CD-12345-XYZ In current situation if user enteres "CD12345" or "CD 12345" nothing is retrieved. Vice versa, if the default_code is CD12345XYZ and user enters "CD-12345" or "CD 12345" nothing is retrieved either. So the solution would be to first remove those special characters from the string being searched for and then search for default_code transformed with some (SQL?) function. Is anything like that possible? One idea comes to mind using computed field where that stripped deault_code would be stored and extending default search to use this. However that would require stored computed field. Any way to prevent this? Thank you. Best regards Radovan Skolnik