Infeasible
Status Update
No update yet.
Comments
yb...@google.com
even if we've provided Iterable, the Cursor under the hood would use limit offset and it is risky if you are not doing a transaction.
if limit offset is fine for you, i recommend just creating that query manually and ensure that your batches are inside the cursor window limit.
more info on this:
https://medium.com/google-developers/large-database-queries-on-android-cb043ae626e8
Sorry, there is not much room can do here :/.
if limit offset is fine for you, i recommend just creating that query manually and ensure that your batches are inside the cursor window limit.
more info on this:
Sorry, there is not much room can do here :/.
an...@gmail.com
Thanks for the feedback. One of the issues with OFFSET is that on some systems it has to scan through to the desired offset. but if that is what is happening under the hood any way then I may as well do so explicitly..
I've read that article you linked, and having had to deal with paging/windowing issues in the past is why I appreciate the new paging library so much.
I could probably see if feeding back the last read id (and LIMIT) results in faster processing than using OFFSET (and LIMIT). E.g.
SELECT *
FROM items
WHERE id > :last_id
ORDER BY id
LIMIT 100
then just iterate until an empty result is returned (or user cancels).
Thanks.
I've read that article you linked, and having had to deal with paging/windowing issues in the past is why I appreciate the new paging library so much.
I could probably see if feeding back the last read id (and LIMIT) results in faster processing than using OFFSET (and LIMIT). E.g.
SELECT *
FROM items
WHERE id > :last_id
ORDER BY id
LIMIT 100
then just iterate until an empty result is returned (or user cancels).
Thanks.
yb...@google.com
yes, you should definitely do that if you have consistent ordering.
That is actually what SQLite recommends:
https://www.sqlite.org/cvstrac/wiki?p=ScrollingCursor
Room cannot do it right now because it requires understanding the query better and also ensuring that the order by statement is unique (e.g. no 2 items have the same order values).
We do have plans to do it eventually especially for non-positional data sources.
That is actually what SQLite recommends:
Room cannot do it right now because it requires understanding the query better and also ensuring that the order by statement is unique (e.g. no 2 items have the same order values).
We do have plans to do it eventually especially for non-positional data sources.
an...@gmail.com
Maybe, initially, restrict it to queries where the ORDER BY clause contains all the columns of the primary key, for single table queries.
It's probably obvious, but perhaps the documentation could indicate that @Query functions returning List<T> will attempt to read everything into memory at once.
The AAC has made a lot of things easier for me already, I hoped that I was perhaps missing something before I do it "the hard way" (not really that hard).
It's probably obvious, but perhaps the documentation could indicate that @Query functions returning List<T> will attempt to read everything into memory at once.
The AAC has made a lot of things easier for me already, I hoped that I was perhaps missing something before I do it "the hard way" (not really that hard).
cc...@google.com
Related to supporting ItemKeyedDataSource in code generation, it would still be a good idea to enable apps to build their own, while Room/Paging managing DB invalidation. Filed
https://b.corp.google.com/issues/109757535 to track this.
Description
I'm already using the [wonderful] paging library for the UI (RecyclerView), but what I need is a way for my background process to read the data sequentially but without loading the entire thing into memory.
Something along the line of:
``` kotlin
@Query("select * from items")
fun allItems(): Iterable<Item>
```
I only need (buffered) forward reading. The table in question is only modified by insertion (and an occasional non-overlapping purge) so would not need transactional protection.
Is there a way to do this in Room? Or do I need to resort to using "limit" in my query?
Component used:
android.arch.persistence.room:runtime
Version used:
1.1.0
Devices/Android versions reproduced on:
If this is a bug in the library, we would appreciate if you could attach:
- Sample project to trigger the issue.
- A screenrecord or screenshots showing the issue (if UI related).