Fixed
Status Update
No update yet.
Comments
ap...@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).
da...@google.com
ra...@gmail.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` ?
Description
To fix
androidx.sqliteare protected from multi-processes racing to create or upgrade the same database file at the same time.