Description
Problem
For the moment, we store all the search parameters as a hive
key, which has limitations (255 ASCII chars).
Advanced search (#1371) means more search parameters than today.
If we want to store searches with many parameters, we cannot use hive
anymore because we'll probably break the 255 char limit.
For the moment in the key we store the search terms (e.g. "pizza"), the country and the language. If we have more parameters, we have the re-think the way search parameters are stored.
Proposed solution
With sqflite
we don't have that 255 char limitation we have in hive
. Therefore a simple fix would be to migrate DaoProductList
from hive
to sqflite
- the only potential problem I see is that we'll have to convert most methods as async
(from what I read in the code the impact would be minimal and there's only one place where we'll need some tap dancing to manage the async
) (namely with getLength
).
In order to manage the increased complexity of the key (not just its bigger length), we could store the key as a json
instead of a mere String
concatenation. This will give us more flexibility - like "reuse a previous search parameters".
Additional context
With @g123k we already evoked the possible migration of DaoProductList
to sqflite
: nothing prevented it, it was just not a priority and the impact on the app would be limited.
For the moment, in hive
the barcode list is stored as a json
. Would it be interesting to store each barcode as a sqflite
table row? Probably not in a first approach, because of the impact on reordering the items (less easy), on space (that means a new row with the barcode and the search key, for each product when it belongs to a list), and there's no visible added value regarding a specific feature.
Part of
Metadata
Assignees
Type
Projects
Status
💬 To discuss and validate