fix: Workaround for too big sqflite tables

[krille-chan]

Closes #1642

[td-famedly]

This looks very specific to read receipts.

2 more general solution IMHO would be:

• Handle this on the client side https://stackoverflow.com/questions/51959944/sqliteblobtoobigexception-row-too-big-to-fit-into-cursorwindow-requiredpos-0-t

• or try to create a custom sqflite db as mentioned here: Window is full tekartik/sqflite#779 (comment)

[krille-chan]

This looks very specific to read receipts.

2 more general solution IMHO would be:

• Handle this on the client side https://stackoverflow.com/questions/51959944/sqliteblobtoobigexception-row-too-big-to-fit-into-cursorwindow-requiredpos-0-t
• or try to create a custom sqflite db as mentioned here: Window is full tekartik/sqflite#779 (comment)

This can be done as well and then the limit can just be disabled on the client side. However this is only a workaround as there is currently no better solution for #1642

[nico-famedly]

I don't think just not storing receipts is a good solution. We could split them up instead of storing them as one large json, which would be better anyway, so that in the future we don't need to load the whole json when we just need a few receipts (like our own). Alternatively one of the approaches to increase the window size on android, since that seems to be the only platform with that problem.

[krille-chan]

I don't think just not storing receipts is a good solution. We could split them up instead of storing them as one large json, which would be better anyway, so that in the future we don't need to load the whole json when we just need a few receipts (like our own). Alternatively one of the approaches to increase the window size on android, since that seems to be the only platform with that problem.

Well I never said this is a good solution or any solution at all. It is a workaround as any other solution would need such a huge change in all databases that it would make much more sense to do this once we have reduced the amount of databases in the sdk. But we cannot reduce the amount of databases as long as the new database is blocked by this edge case. So what solution would you suggest which does not need another weeks of development?

[krille-chan]

Closed because I found a better solution

[Malesenka]

thx