Fixed
Status Update
No update yet.
Comments
yb...@google.com
Also, it would be great to return Observable, cause Flowable has some overhead.
an...@gmail.com
We are going to add Single for queries (and Maybe) but for @insert, @Update and @Delete it is a bit more tricky because we would be reading those values when the computable runs, in which case developer may change them by mistake. We've not decided whether we want to take that risk or not. (We could copy but that would be additional hidden load, especially if the input is a long list).
#2, flowable can easily turn into an observable, would you like to escalate on why you think the overhead is a problem?
#2, flowable can easily turn into an observable, would you like to escalate on why you think the overhead is a problem?
fr...@gmail.com
Cool for Single/Maybe for queries :)
For @insert, @Update and @Delete I personally would like to have the possibility to have Single/Maybe... because I will 100% of the time wrap the call into a Single to make it asynchronous and have the possibility to chain other actions with it. I understand that copying entries will take additional resources but in that case we'll have the possibility to not use the RX return type.
That my opinion ^^
Thanks !
For @insert, @Update and @Delete I personally would like to have the possibility to have Single/Maybe... because I will 100% of the time wrap the call into a Single to make it asynchronous and have the possibility to chain other actions with it. I understand that copying entries will take additional resources but in that case we'll have the possibility to not use the RX return type.
That my opinion ^^
Thanks !
da...@google.com
xm...@gmail.com
Shouldn't this be typed as a feature request?
mu...@gmail.com
wo...@gmail.com
This issue is half year old and it's still not implemented. Without this the library is unusable.
ya...@google.com
ap...@google.com
+1
ya...@google.com
to...@gmail.com
+1 Here as well. I would like Completable support.
jp...@gmail.com
+1 i think Completable support is necessary
Description
Version used: 1.0.0-beta1
Devices/Android versions reproduced on: n/a
There appears to be no way to execute a CREATE VIEW in a way that Room will recognize. Instead, developers seem to need some icky workarounds (see
My guess is that there should be a VIEW equivalent of @Entity, where the annotation takes the SELECT statement to go after the AS in the CREATE VIEW statement, where the Room compiler then assembles the rest.
Alternatively, @Entity could be extended to support views (e.g., via a viewSelect annotation property that triggers CREATE VIEW instead of CREATE TABLE logic). Bonus points here: there's no need to figure out the right annotation for a VIEW (since @View probably has been used 28 times already in various Android annotation processors...). :-)
Thanks for considering this!