Fixed
Status Update
No update yet.
Comments
yb...@google.com
For a reproduction case:
1. Downloadhttps://github.com/romannurik/muzei
2. Checkout to room-issue-2.1.0-alpha03 tag
3. Change the ProviderDao to abstract suspend fun insert(provider: Provider)
4. Run the app, hit the Activate button
Expected Result: the image is loaded
Actual Result: the insert never returns (you only see a black screen), blocking the arch thread forever
1. Download
2. Checkout to room-issue-2.1.0-alpha03 tag
3. Change the ProviderDao to abstract suspend fun insert(provider: Provider)
4. Run the app, hit the Activate button
Expected Result: the image is loaded
Actual Result: the insert never returns (you only see a black screen), blocking the arch thread forever
yb...@google.com
this is partially fixed in
https://android-review.googlesource.com/c/platform/frameworks/support/+/850190
though with usages of begin / end; worse situations can happen that we cannot recover.
A full fledged fix requires a new transaction API.
That being said, if app uses db.runInTrasaction; this bug would not happen (because you cannot launch inside it).
maybe we should deprecate begin/end ?
though with usages of begin / end; worse situations can happen that we cannot recover.
A full fledged fix requires a new transaction API.
That being said, if app uses db.runInTrasaction; this bug would not happen (because you cannot launch inside it).
maybe we should deprecate begin/end ?
za...@gmail.com
back to p2 since the most pressing part is fixed.
za...@gmail.com
As I understand it, any non-Room suspending method in the middle of a transaction will still break since you might resume the coroutine on a different thread?
I think I'd personally really like an extension method of:
fun RoomDatabase.transaction(body: suspend () -> Unit)
that replaces / obsoletes runInTransaction and would be safe to do both Room suspend methods and other, non-Room suspend methods, always returning to the correct thread for the transaction.
I think I'd personally really like an extension method of:
fun RoomDatabase.transaction(body: suspend () -> Unit)
that replaces / obsoletes runInTransaction and would be safe to do both Room suspend methods and other, non-Room suspend methods, always returning to the correct thread for the transaction.
yb...@google.com
da...@google.com
yea the issue w/ suspending room version is that we need to make sure we can carry over the transaction information so that it can go to the right thread and only it (not some other parallel task).
This is why we need a proper transaction abstraction to safely do these jumps (or at least thats what i thnk we'll need, maybe not)
This is why we need a proper transaction abstraction to safely do these jumps (or at least thats what i thnk we'll need, maybe not)
Description
Version used: 1.1.0-present
Theme used: NA
Devices/Android versions reproduced on: NA build-time
- Relevant code to trigger the issue: Any kotlin data class in an external module. Building the following project can reproduce it:
In Kotlin, data classes will have a primary constructor and sometimes generated synthetic constructors. ROOM's processor will complain about the presence of the synthetic ones (which are usually visible when reading the class file from an external library), but since it's reading metadata it could use it to find the "primary" constructor to know for sure.
Example:
The solution would be to find that constructor, then match it to the corresponding constructor as seen in the elements API