Fixed
Status Update
No update yet.
Comments
yb...@google.com
da...@google.com
For one of observables (single, maybe) we don't specify a subscvription thread so that developer can control where the action happens.
For flowables / observables; we always use the Room IO thread fo rthe actual query since we may repeat the work.
For LiveData, ti si always the Room IO Thread.
Until we can extend Room Query methods to receive non-query parameter (e.g. a Scheduler) we cannot do this.
At least room catches this instantly since it will crash w/ db access on main thread exception.
For flowables / observables; we always use the Room IO thread fo rthe actual query since we may repeat the work.
For LiveData, ti si always the Room IO Thread.
Until we can extend Room Query methods to receive non-query parameter (e.g. a Scheduler) we cannot do this.
At least room catches this instantly since it will crash w/ db access on main thread exception.
Description
Version used:1.1.1
Devices/Android versions reproduced on: All
File: FrameworkSQLiteOpenHelper
OpenHelper(Context context, String name, final FrameworkSQLiteDatabase[] dbRef,
final Callback callback) {
super(context, name, null, callback.version,
new DatabaseErrorHandler() {
@Override
public void onCorruption(SQLiteDatabase dbObj) {
FrameworkSQLiteDatabase db = dbRef[0];
if (db != null) {
callback.onCorruption(db);
}
}
});
mCallback = callback;
mDbRef = dbRef;
}
callback.onCorruption(db) will never called when the db is corrupted, cause dbRef[0] always is null.
Maybe this code is better:
OpenHelper(Context context, String name, final FrameworkSQLiteDatabase[] dbRef,
final Callback callback) {
super(context, name, null, callback.version,
new DatabaseErrorHandler() {
@Override
public void onCorruption(SQLiteDatabase dbObj) {
FrameworkSQLiteDatabase db = dbRef[0];
callback.onCorruption(db != null ? db : new FrameworkSQLiteDatabase(dbObj));
}
});
mCallback = callback;
mDbRef = dbRef;
}