-
Notifications
You must be signed in to change notification settings - Fork 657
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SQLiteBlobTooBigException: Row too big to fit into CursorWindow #4072
Comments
Hi! 👋 Thank you for reporting this! From what I am gathering online it's not 100% clear whether this can happen when individual rows are too big, or if it can also be related to the total size of the query. Does your app clears the SQL cache (with Also, this doesn't address the root cause, but if you update to v3.2.1 or later (latest is 3.2.2), such exceptions will be caught and treated as a cache miss - which is of course not perfect but better than crashing. The exception will be logged by default but you can have a custom tracking by setting |
Hi @BoD, Thanks for your reply. |
Clearing it at logout sounds good to me 👍. Even though I suspect most users don't logout often (well that depends on the app of course). The reason I asked is that right now there aren't ways to automatically remove old entries from the cache (that's on the roadmap) so in the current situation it could grow forever if it is never manually cleaned - but to be honest that would still not explain the exception you're seeing, it's just something to think about.
👍 |
@BoD For me the root cause of this error is e.g.:
For now my fix was to set Btw: on Android this exception is handled as you wrote with cache miss .. but on iOS it will load to memory and cause OOMs errors. |
Thanks a lot for the feedback @Mordred, that's very valuable. That would explain it indeed. |
Yes, but this can be a problem for queries too .. e.g. query which accept filter and pagination cursor. Is it possible to detect this and clear unused data automatically or manually? |
@Mordred You can use For automatic detection, there is an experimental TrimmableNormalizedCache in the 'incubating' normalized cache artifacts. This is not ready for production, but if you'd like to give it a try, you can replace your While I'm in the experimental/incubating area, let's also mention an improved support for pagination (several pages can be stored at a unique cache key) which you may also find interesting. Sorry there is no documentation on this yet but an example can be seen here. |
Since the migration from Apollo 2 .5.11 to Apollo 3.1.0, many users are getting SQLiteBlobTooBigException when executing queries.
I didn't found any scenarios to reproduce the issue and users get the issue with several queries.
Here is the stack trace:
The text was updated successfully, but these errors were encountered: