[16.0][IMP] shopfloor: improve performance of generic_find

[nicolas-delbovier-acsone]

Problem

The generic_find method in shopfloor suffered from two performance bottlenecks during barcode scanning:

1. Redundant Handler Scans: Even when the parser successfully identified a highly specific barcode type (e.g., a GS1 'lot'), the loop structure would blindly execute database queries across all other active handlers (e.g., 'package', 'product', 'location').
2. Suboptimal Order of Execution: Because the parser sequence injects an "unknown" result type (representing the raw string fallback) at the beginning of the results collection, the method consistently evaluated this generic fallback first (and thus tested all possible types instead of only one).

---

Also includes

• Found a file not named properly in shopfloor_gs1 -> renamed to not be misleading in the future / improve code navigation

[OCA-git-bot]

Hi @sebalix, @simahawk, @guewen,
some modules you are maintaining are being modified, check this out!

[nicolas-delbovier-acsone]

@jbaudoux

[jbaudoux]

Definitely better but not enough.
I think I explained it in the issue. You need to loop over each result and their type to refine the result.
First result is ean, search for products. Next result is lot, search for lots of found products. Etc...

[simahawk]

is this change really needed?

[nicolas-delbovier-acsone]

I am not against reverting this change if really you prefer so.

I was just applying the "boy scout rule" to bring this file name in line with naming conventions while I was working in the area.

[nicolas-delbovier-acsone]

Definitely better but not enough. I think I explained it in the issue. You need to loop over each result and their type to refine the result. First result is ean, search for products. Next result is lot, search for lots of found products. Etc...

I do not understand how what you say could work? Ingeneric_find, once a record is found, the method returns (thus the importance of the ordering of the types). Therefore, there is no way to "refine" results for later searches...

Are you suggesting that we should not return on first result found and always test all possible types first and then decide which record I want to link to the returned SearchResult in case of collisions (e.g. lot and package sharing the same name) ? Wouldn't this make the search slower while in most cases such a collision should be rare? How do we decide which record is the best to return in case of multiple records found ?

[jbaudoux]

Definitely better but not enough. I think I explained it in the issue. You need to loop over each result and their type to refine the result. First result is ean, search for products. Next result is lot, search for lots of found products. Etc...

I do not understand how what you say could work? Ingeneric_find, once a record is found, the method returns (thus the importance of the ordering of the types). Therefore, there is no way to "refine" results for later searches...

Are you suggesting that we should not return on first result found and always test all possible types first and then decide which record I want to link to the returned SearchResult in case of collisions (e.g. lot and package sharing the same name) ? Wouldn't this make the search slower while in most cases such a collision should be rare? How do we decide which record is the best to return in case of multiple records found ?

Yes you need to process all the results and parse according their type. The one to return is the last that made a match. If you match a lot, you return the lot. If you match only a product, you return a product.