Fixed
Status Update
No update yet.
Comments
be...@google.com
since these are in public API (:/) we need to do this in 1.2
se...@google.com
since it is already marked as deprecated, we can probably do it by now.
be...@google.com
Opening diff shortly
mm...@commonsware.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit d576cbdc911cba16638a44fd8223391a90a07ef7
Author: Mike Nakhimovich <digitalbuddha@users.noreply.github.com>
Date: Tue Aug 11 09:30:34 2020
[GH] Hide deprecated internal API.
## Proposed Changes
* `RoomDatabase.java` has protected `mCallbacks` field which is leaking in the API docs, we should @Hide it.
## Testing
Test: Ran unit tests locally
## Issues Fixed
Fixes: 76109329
This is an imported pull request fromhttps://github.com/androidx/androidx/pull/61 .
Resolves #61
Github-Pr-Head-Sha: 6440daa3a63752c7f9d5ba2a390248cd85bc634f
GitOrigin-RevId: fe92d8466a59b44b218b6ca3cbd57dcda17992f7
Change-Id: Id599cdf5b02b32bdae0166266fb7da967598fe92
A room/runtime/api/current.ignore
M room/runtime/api/current.txt
M room/runtime/api/public_plus_experimental_current.txt
M room/runtime/api/restricted_current.txt
M room/runtime/src/main/java/androidx/room/RoomDatabase.java
https://android-review.googlesource.com/1396827
Branch: androidx-master-dev
commit d576cbdc911cba16638a44fd8223391a90a07ef7
Author: Mike Nakhimovich <digitalbuddha@users.noreply.github.com>
Date: Tue Aug 11 09:30:34 2020
[GH] Hide deprecated internal API.
## Proposed Changes
* `RoomDatabase.java` has protected `mCallbacks` field which is leaking in the API docs, we should @Hide it.
## Testing
Test: Ran unit tests locally
## Issues Fixed
Fixes: 76109329
This is an imported pull request from
Resolves #61
Github-Pr-Head-Sha: 6440daa3a63752c7f9d5ba2a390248cd85bc634f
GitOrigin-RevId: fe92d8466a59b44b218b6ca3cbd57dcda17992f7
Change-Id: Id599cdf5b02b32bdae0166266fb7da967598fe92
A room/runtime/api/current.ignore
M room/runtime/api/current.txt
M room/runtime/api/public_plus_experimental_current.txt
M room/runtime/api/restricted_current.txt
M room/runtime/src/main/java/androidx/room/RoomDatabase.java
ya...@google.com
When a query returns too many rows to fit in a CursorWindow, how does wrapping it in a transaction make it consistent?
yb...@google.com
because it holds a transaction in the database, it will isolate the queries.
Cursor does this weird thing where it re-runs the query to fill the next window. Since it is another query, unless there is a transaction, it may load totally different data.
i don't like the idea of turning it on for every single query because it will simply make the db access single threaded for a super super edge case (especially after we have paging).
maybe we can make it a builder parameter (off by default) and also support @Transaction in selection methods?
Cursor does this weird thing where it re-runs the query to fill the next window. Since it is another query, unless there is a transaction, it may load totally different data.
i don't like the idea of turning it on for every single query because it will simply make the db access single threaded for a super super edge case (especially after we have paging).
maybe we can make it a builder parameter (off by default) and also support @Transaction in selection methods?
se...@google.com
how about
we can make query -> see that results are larger than page -> add transaction -> rerun query + (print warning ?). So at least we would provide always safe behaviour. Plus we still have unsafe option that turns it off.
we can make query -> see that results are larger than page -> add transaction -> rerun query + (print warning ?). So at least we would provide always safe behaviour. Plus we still have unsafe option that turns it off.
yb...@google.com
i think ccraik@ had a way of figuring it out in the framework SQLiteCursor. Unfortunately, it is hidden because of the abstraction but we can make it a first class api in the abstraction.
I think we can even implement this in the framework impl (db-impl module) to completely hide from the generated code.
I think we can even implement this in the framework impl (db-impl module) to completely hide from the generated code.
yb...@google.com
this may require an API change so moving to beta1 hotlist.
yb...@google.com
i think for now we should just ensure that Relationship queries are fetched in a transaction so that they are consistent.
If we can implement this in a cursor wrapper, that would be the best.
Besides, this is something that needs to be handled in the FrameworkSQLiteDatabase since it is the only one that can figure out the windowing.
As long as the Cursor is not passed to the outside world, it seems reasonable to create a cursor wrapper that holds a transaction until it is closed.
If we can implement this in a cursor wrapper, that would be the best.
Besides, this is something that needs to be handled in the FrameworkSQLiteDatabase since it is the only one that can figure out the windowing.
As long as the Cursor is not passed to the outside world, it seems reasonable to create a cursor wrapper that holds a transaction until it is closed.
yb...@google.com
decided to punt on this till after 1.0 release.
Description
we should probably wrap all reads into a transaction. This will slow down parallel reads (because android grabs locks in java level) but maybe it is worth the improvement. Alternatively, we can support @Transaction annotation in queries and let the developer decide.