Fixed
Status Update
Comments
yb...@google.com <yb...@google.com> #2
Thanks for reporting this - Looks like Room is trying to give you a warning, possibly POJO & query result column mismatch, but it fails format the message. I guess safeFormat() is not very safe after all. >.>
Could you please provide your full method signature for the failing query method case? If the return type is a data class it would be nice if you could also provide it.
Could you please provide your full method signature for the failing query method case? If the return type is a data class it would be nice if you could also provide it.
[Deleted User] <[Deleted User]> #3
What is the alarm sounds that every seems to know about but me it's like I'm being tracked everywhere I go
yb...@google.com <yb...@google.com> #4
Project: platform/frameworks/support
Branch: androidx-master-dev
commit c08fa5ad19b227e73cfcf9fd8e0994ec32273bce
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Wed Nov 14 13:38:50 2018
Make RLog's safeFormat() truly safe by catching all exceptions.
Bug: 119520136
Test: RLogTest
Change-Id: I81c8a4ed9e03b64d6762a9976d2dfcd12ea8327b
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
A room/compiler/src/test/kotlin/androidx/room/log/RLogTest.kt
https://android-review.googlesource.com/826949
https://goto.google.com/android-sha1/c08fa5ad19b227e73cfcf9fd8e0994ec32273bce
Branch: androidx-master-dev
commit c08fa5ad19b227e73cfcf9fd8e0994ec32273bce
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Wed Nov 14 13:38:50 2018
Make RLog's safeFormat() truly safe by catching all exceptions.
Bug: 119520136
Test: RLogTest
Change-Id: I81c8a4ed9e03b64d6762a9976d2dfcd12ea8327b
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
A room/compiler/src/test/kotlin/androidx/room/log/RLogTest.kt
[Deleted User] <[Deleted User]> #5
A fix for this will be available in Room 2.1.0-alpha03
yb...@google.com <yb...@google.com> #6
Great news -- thank you for fast turnaround!
ap...@google.com <ap...@google.com> #7
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 9b78b58d3758e84a5c4a26c812e1164076552e3e
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Tue Jan 15 13:10:58 2019
Disallow @Transaction implementations with async return types.
Since we cannot reasonably defer begin and end transactions in a
implemented DAO method that returns an async type then throw an error
if such method is detected.
Bug: 120109336
Test: ./gradlew room:room-compiler:test
Change-Id: Ifa1bf55cc736ad7c4735043e5b8bac6cd7954ab7
M room/compiler/src/main/kotlin/androidx/room/processor/ProcessorErrors.kt
M room/compiler/src/main/kotlin/androidx/room/processor/TransactionMethodProcessor.kt
M room/compiler/src/test/kotlin/androidx/room/processor/TransactionMethodProcessorTest.kt
https://android-review.googlesource.com/873033
https://goto.google.com/android-sha1/9b78b58d3758e84a5c4a26c812e1164076552e3e
Branch: androidx-master-dev
commit 9b78b58d3758e84a5c4a26c812e1164076552e3e
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Tue Jan 15 13:10:58 2019
Disallow @Transaction implementations with async return types.
Since we cannot reasonably defer begin and end transactions in a
implemented DAO method that returns an async type then throw an error
if such method is detected.
Bug: 120109336
Test: ./gradlew room:room-compiler:test
Change-Id: Ifa1bf55cc736ad7c4735043e5b8bac6cd7954ab7
M room/compiler/src/main/kotlin/androidx/room/processor/ProcessorErrors.kt
M room/compiler/src/main/kotlin/androidx/room/processor/TransactionMethodProcessor.kt
M room/compiler/src/test/kotlin/androidx/room/processor/TransactionMethodProcessorTest.kt
Description
Version used: 2.0.0
Devices/Android versions reproduced on: N/A
In current version of room if I mark method in DAO with @Transaction, and if it uses any disposable e.g. Single, the generated code will throw main thread access exception at runtime.
I would expect one of two behaviours instead:
1. It would be ideal if room could somehow defer start/end transaction to match thread that is used on Disposable, but I can imagine that this can be not possible.
2. To get compile time warning or error that this may be not the correct way of using @Transaction with mix of asynchronous code.
Example of code:
Method in abstract DAO:
@Transaction
open fun upsert(obj: T): Single<Boolean> {
return insert(obj)
.map { true }
.onErrorResumeNext {
if (it is SQLiteConstraintException)
{ update(obj)
.map { true }
} else {
Single.error(it) }
}
.subscribeOn(Schedulers.io()) }
Generated method:
@Override
public Single<Boolean> upsert(Supplier obj) {
__db.beginTransaction();
try {
Single<Boolean> _result = super.upsert(obj);
__db.setTransactionSuccessful();
return _result;
} finally {
__db.endTransaction();
}
}