Fixed
Status Update
No update yet.
Comments
el...@google.com
Could this also help with the problem where a non-nullable type can be null because nullability is not inferred in the generated Java code? E.g., having a query returning a LiveData<Pojo> but the table of Pojo's is empty so the LiveData will trigger an update with a null value that shouldn't be null (or maybe that is a plain bug).
el...@google.com
Actually for that, maybe we can start reading the nullability annotation and respect that?
It might get a bit more complicated with regular returns.
e.g. if you write
@Query(...)
suspend fun getUser(id:String) : User
do we throw NPE if user does not exist? i guess we have to.
So then this would be only for `Flow` and `LiveData` return types and i hope we already handle nullability for `FLow` ?
It might get a bit more complicated with regular returns.
e.g. if you write
@Query(...)
suspend fun getUser(id:String) : User
do we throw NPE if user does not exist? i guess we have to.
So then this would be only for `Flow` and `LiveData` return types and i hope we already handle nullability for `FLow` ?
ap...@google.com
From what I can see, there is no nullability annotation in the generated DAO code (as of Room 2.2.0-rc01) when returning LiveData. The result object is declared and returned uninitialized if the cursor is empty. Or I might be reading it wrong.
el...@google.com
pr...@google.com
VOTE +100500
Description
Room will never return a null array. This is the same as :