Fixed
Status Update
No update yet.
Comments
yb...@google.com
for the query1:
The problem is partially due to studio not showing kapt warnings. Room actually prints a warning if you run form command line:
w: /Users/yboyar/Documents/git/room-bugs/RoomBug/app/build/tmp/kapt3/stubs/debug/com/example/lorenzo/roombug/EntityDao.java:9: warning: The query returns some columns [isThisABug] which are not use by com.example.lorenzo.roombug.SecondEntity. You can use @ColumnInfo annotation on the fields to specify the mapping. com.example.lorenzo.roombug.SecondEntity has some fields [isThisNotABug] which are not returned by the query. If they are not supposed to be read from the result, you can mark them with @Ignore annotation. You can suppress this warning by annotating the method with @SuppressWarnings(RoomWarnings.CURSOR_MISMATCH). Columns returned by the query: id, isThisABug. Fields in com.example.lorenzo.roombug.SecondEntity: id, isThisNotABug.
On the other hand, Room could be more clever and fail compilation instead of a warning because the field is marked as non-null.
The problem is partially due to studio not showing kapt warnings. Room actually prints a warning if you run form command line:
w: /Users/yboyar/Documents/git/room-bugs/RoomBug/app/build/tmp/kapt3/stubs/debug/com/example/lorenzo/roombug/EntityDao.java:9: warning: The query returns some columns [isThisABug] which are not use by com.example.lorenzo.roombug.SecondEntity. You can use @ColumnInfo annotation on the fields to specify the mapping. com.example.lorenzo.roombug.SecondEntity has some fields [isThisNotABug] which are not returned by the query. If they are not supposed to be read from the result, you can mark them with @Ignore annotation. You can suppress this warning by annotating the method with @SuppressWarnings(RoomWarnings.CURSOR_MISMATCH). Columns returned by the query: id, isThisABug. Fields in com.example.lorenzo.roombug.SecondEntity: id, isThisNotABug.
On the other hand, Room could be more clever and fail compilation instead of a warning because the field is marked as non-null.
yb...@google.com
The case is the same for the second one, except kotlin compiler does not know it because it is called from java code.
lo...@gmail.com
Yes, exactly the point: compilation should fail with a better error message when the field is declared as not null. Also, have you ever thought about a lint check when a query from a table returns an entity connected to another table? My point is that 99% of the cases where this happens are just silly mistakes and trying to be really explicit with the user about this could be really helpful
yb...@google.com
changing this will have an ugly side effect though. If it is primitive, we do have a default but enforcing these will require us to fail and enforce developer to return that column as well. Though maybe it is the right thing to do anyways.
yb...@google.com
i don't think we'll do the other table case as it is valid if someone has identical content tables.
Moreover, Room does not consider that return value as an Entitiy, rather it considers it as a regular pojo.
Moreover, Room does not consider that return value as an Entitiy, rather it considers it as a regular pojo.
yb...@google.com
ok I have a CL ready for this. Hopefully should be in beta2.
lo...@gmail.com
That was fast, thanks Yigit!
Description
Version used: beta-1
Devices/Android versions reproduced on: happens at compile time
The sample project attached to this bug report shows that Room does not check if I'm trying to get an entity from another table. The consequence is that sometimes I get an error which doesn't really say much: "error: incompatible types: <null> cannot be converted to boolean". This error is triggered by Kotlin's Boolean, which in the bytecode can be sometimes primitive types and so null fails to match. But when using another type, everything would be fine except that we are querying the wrong table for that entity.
See in the sample project the SomeDao.kt class: the first query causes a compile time error, while the second one (which for me is still invalid and would crash immediately in Kotlin since the type is non null) apparently is OK (is that expected? I understand that this is what allows Room to returns a different object from the entity and that's really powerful, but at the same time it opens the doors for a lot of mistakes which won't be catched at compile time)