We can search records (Find Window) regardless if the case is upper or lower, so this is a case insensitive search. This feature allows you to perform accent insensitive search.
If you try to search 'avião' it will show results for 'aviao' and 'avião'.
This works on both Oracle and Postgres.
Hi , the patch contains a reference to Util.deleteAccents which is not in code.
This creates also a dependency with external postgresql functions as the unaccent is not part of the default postgres installation.
The idea sounds great, but I think is hard to get it directly in core, maybe we can try to find a way to make the find window operators extensible.
Hi , I'm sorry to insist in this topic, but I want you to take some things in consideration:
1) The Util.deleteAccents is in the code AFAIK, please check:
2) The UUID-OSSP is an "Additional Supplied Modules" from PostgreSQL, the same for UNACCENT module, so I don't think this will make any more DB dependent as it already is today.
3) The menu search is already accent insensitive, I think this feature request will make the iDempiere more consistent, because today the menu search and the record search has different behaviors.
Even though, if you think it should be done differently, I will work on it.
Thanks , reopening this per your request.
1) You're right about Util.deleteAccents - now I remember, sorry about missing that one.
2) the uuid effectively is external, and precisely that's the reason I'm concerned about that - because of differences on the uuid implementation we needed to have maintain two versions for a while, it also adds some prerequisites to the installation.
For these cases I think is better to allow implementing as an external plugin.
3) I'm not against the feature, I find it very useful as spanish has accents and different people use accents in different ways.
But I'm not sure is about the implementation.
In the tests of I noticed that comparing java functions vs DB functions is not a good idea - in that case it was the uppercase/upper bringing different results. But also as you noted there the unaccent function was bringing different results on different postgres versions, so comparing that against a "java unaccent" doesn't sound safe.
The solution in in the end was to apply the DB function to both sides, the parameter and the column, so I think the unaccent_upper can follow the same approach to be safe.
Also, there must be some indexes in the DB that uses upper - and in this case it would be come useless, the implementation would change better that to unaccent_upper in the index.
Those are my considerations. Would be good to collect opinions from others too, I find this valuable.