IssueTracker

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).

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` ?

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.