Fixed
Status Update
Comments
yb...@google.com <yb...@google.com>
ya...@google.com <ya...@google.com>
ap...@google.com <ap...@google.com> #2
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
@Dao
interface MyDao {
@Query("DELETE FROM mytable WHERE id IN (:ids)")
fun deleteByIds(ids: Collection<String>)
}
Results in the following error:
e: error: Query method parameters should either be a type that can be converted into a database column or a List / Array that contains such type. You can consider adding a Type Adapter for this. - arg0 in deleteByIds(java.util.Collection<java.lang.String>)
Currently we can pass only List, Array and Set (not mentioned in the error message) to IN operator but it should be possible to pass Collection too.