Fixed
Status Update
Comments
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
I don't see why we cannot support it since from a relation's perspective, it is like an entity.
This is quite critical as it allows extending scope of relationships.