Kotlin DAO function implementation for @RawQuery wrong value for Double [304584179]

Fixed

Bug

Status Update

No update yet.

Description

md...@gmail.com

created issue #1

Oct 11, 2023 06:09AM

Component used:androidx.room:room-ktx
Version used:"2.6.0-rc01"
Devices/Android versions reproduced on: Not related

Kotlin implementation of DAO for @RawQuery function implementation with return type Double is initailised with 0 instead of 0.0 on null check.

@Entity
class Test(@PrimaryKey val d: Double, val l: Long) {
@Dao
interface TestDao {
@RawQuery
fun getLocation(query: SupportSQLiteQuery): Test
}
}

For this setup Room generates the following implementation:

private fun __entityCursorConverter_comTest(cursor: Cursor): Test {
val _entity: Test
val _cursorIndexOfD: Int = getColumnIndex(cursor, "d")
val _cursorIndexOfL: Int = getColumnIndex(cursor, "l")
val _tmpD: Double
if (_cursorIndexOfD == -1) {
_tmpD = 0 //Error: The integer literal does not conform to the expected type Double
} else {
_tmpD = cursor.getDouble(_cursorIndexOfD)
}
val _tmpL: Long
if (_cursorIndexOfL == -1) {
_tmpL = 0
} else {
_tmpL = cursor.getLong(_cursorIndexOfL)
}
_entity = Test(_tmpD,_tmpL)
return _entity
}

Comments

ma...@mark43.com <ma...@mark43.com> #2Oct 17, 2023 05:26PM

Comment has been deleted.

Message last modified on Oct 17, 2023 10:15PM

el...@google.com <el...@google.com> #3Oct 17, 2023 10:33PM

Hello Yigit, nice to meet you here! :)
Probably I should have described the problem more clearly.

I'm using Flowable, and hopefully it executes queries in background thread (at least, app does not crash with IllegalStateException, as with Single).

But nevertheless subscribing and disposing(!) does cause StrictMode violations. Stack trace examples:

D/StrictMode: StrictMode policy violation; ~duration=17 ms: android.os.StrictMode$StrictModeDiskWriteViolation: policy=31 violation=1
at android.os.StrictMode$AndroidBlockGuardPolicy.onWriteToDisk(StrictMode.java:1111)
at android.database.sqlite.SQLiteConnection.applyBlockGuardPolicy(SQLiteConnection.java:1043)
at android.database.sqlite.SQLiteConnection.execute(SQLiteConnection.java:552)
at android.database.sqlite.SQLiteSession.beginTransactionUnchecked(SQLiteSession.java:323)
at android.database.sqlite.SQLiteSession.beginTransaction(SQLiteSession.java:298)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:505)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:416)
at androidx.sqlite.db.framework.FrameworkSQLiteDatabase.beginTransaction(FrameworkSQLiteDatabase.java:69)
at androidx.room.InvalidationTracker.syncTriggers(InvalidationTracker.java:426)
at androidx.room.InvalidationTracker.syncTriggers(InvalidationTracker.java:465)
at androidx.room.InvalidationTracker.addObserver(InvalidationTracker.java:249)
at androidx.room.RxRoom$1.subscribe(RxRoom.java:79)
at io.reactivex.internal.operators.flowable.FlowableCreate.subscribeActual(FlowableCreate.java:71)
at io.reactivex.Flowable.subscribe(Flowable.java:14479)
at io.reactivex.internal.operators.flowable.FlowableObserveOn.subscribeActual(FlowableObserveOn.java:56)
at io.reactivex.Flowable.subscribe(Flowable.java:14479)
at io.reactivex.internal.operators.flowable.FlowableFlatMapMaybe.subscribeActual(FlowableFlatMapMaybe.java:54)
at io.reactivex.Flowable.subscribe(Flowable.java:14479)
at io.reactivex.Flowable.subscribe(Flowable.java:14416)
at io.reactivex.Flowable.subscribe(Flowable.java:14306)
at gmk57.strictroom.MainActivity.onCreate(MainActivity.java:30)

StrictMode policy violation; ~duration=108 ms: android.os.StrictMode$StrictModeDiskWriteViolation: policy=31 violation=1
at android.os.StrictMode$AndroidBlockGuardPolicy.onWriteToDisk(StrictMode.java:1111)
at android.database.sqlite.SQLiteConnection.applyBlockGuardPolicy(SQLiteConnection.java:1043)
at android.database.sqlite.SQLiteConnection.execute(SQLiteConnection.java:552)
at android.database.sqlite.SQLiteSession.beginTransactionUnchecked(SQLiteSession.java:323)
at android.database.sqlite.SQLiteSession.beginTransaction(SQLiteSession.java:298)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:505)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:416)
at androidx.sqlite.db.framework.FrameworkSQLiteDatabase.beginTransaction(FrameworkSQLiteDatabase.java:69)
at androidx.room.InvalidationTracker.syncTriggers(InvalidationTracker.java:426)
at androidx.room.InvalidationTracker.syncTriggers(InvalidationTracker.java:465)
at androidx.room.InvalidationTracker.removeObserver(InvalidationTracker.java:281)
at androidx.room.RxRoom$1$2.run(RxRoom.java:83)
at io.reactivex.disposables.ActionDisposable.onDisposed(ActionDisposable.java:30)
at io.reactivex.disposables.ActionDisposable.onDisposed(ActionDisposable.java:19)
at io.reactivex.disposables.ReferenceDisposable.dispose(ReferenceDisposable.java:43)
at io.reactivex.internal.disposables.DisposableHelper.dispose(DisposableHelper.java:124)
at io.reactivex.internal.disposables.SequentialDisposable.dispose(SequentialDisposable.java:72)
at io.reactivex.internal.operators.flowable.FlowableCreate$BaseEmitter.cancel(FlowableCreate.java:301)
at io.reactivex.internal.operators.flowable.FlowableObserveOn$BaseObserveOnSubscriber.cancel(FlowableObserveOn.java:154)
at io.reactivex.internal.operators.flowable.FlowableFlatMapMaybe$FlatMapMaybeSubscriber.cancel(FlowableFlatMapMaybe.java:158)
at io.reactivex.internal.subscriptions.SubscriptionHelper.cancel(SubscriptionHelper.java:189)
at io.reactivex.internal.subscribers.LambdaSubscriber.cancel(LambdaSubscriber.java:119)
at io.reactivex.internal.subscribers.LambdaSubscriber.dispose(LambdaSubscriber.java:104)
at gmk57.strictroom.MainActivity.onDestroy(MainActivity.java:37)

el...@google.com <el...@google.com> Oct 18, 2023 05:13PM

Marked as fixed.

ap...@google.com <ap...@google.com> #4Oct 18, 2023 05:15PM

oh this is bad :/ we should fix it, thanks!

pr...@google.com <pr...@google.com> #5Nov 29, 2023 09:39PM

Looks like it is broken for both add observer and remove observer since both are sync.
We need to investigate this better because these methods were not @WorkerThread before and we had to change them to fix some invalidation problems (see internal bug

b/73592149

).
Luckily this is not an issue for LiveData since it uses ComputableLiveData and always calls observe on a background thread.

Issue 304584179