Status Update
Comments
da...@google.com <da...@google.com> #2
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
el...@google.com <el...@google.com>
da...@google.com <da...@google.com>
ap...@google.com <ap...@google.com> #3
da...@google.com <da...@google.com>
[Deleted User] <[Deleted User]> #4
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
da...@google.com <da...@google.com> #5
Sorry, the fix for this issue is in Room 2.5.0 and not 2.4.x, we are working on getting a stable release of 2.5.0 soon.
th...@gmail.com <th...@gmail.com> #6
Need to know if I should wait for the update or refactor my code.
da...@google.com <da...@google.com> #7
Room 2.5.0-rc01 was recently released, the next release will be 2.5.0. Unfortunately the US holidays are around the corner and the next androidx release will be early next year.
ne...@gmail.com <ne...@gmail.com> #8
Room 2.5.1, this issue still exists when selecting using a join to filter data but omitting the joined data in the result. E.g. when Entity1
has column named id
and Entity2
also has id
, and I use a @Query
that returns a List<Entity1>
with a simple join in order to filter only those of Entity1
who have a relation to certain Entity2
. The resulting List<Entity1>
contains instances of Entity1
whose ids are wrongly assigned to those of their respective joined Entity2
. And that is regardless whether @RewriteQueriesToDropUnusedColumns
is being used or not.
yb...@google.com <yb...@google.com> #9
#8, can you provide a sample app that reproduces that error? Seeing the query + entity1/2 should be enough. thanks.
be...@gmail.com <be...@gmail.com> #10
I'm also still seeing this issue in Room 2.6.0. I'm able to produce it using the query from the "
@Query(
"SELECT * FROM book " +
"INNER JOIN loan ON loan.book_id = book.id " +
"INNER JOIN user ON user.id = loan.user_id " +
"WHERE user.name LIKE :userName"
)
fun findBooksBorrowedByNameSync(userName: String): List<Book>
I created these entities to go with it:
@Entity
data class Book(
@PrimaryKey(autoGenerate = true) val id: Int,
val title: String,
)
@Entity
data class Loan(
@PrimaryKey(autoGenerate = true) val id: Int,
@ColumnInfo(name = "book_id") val bookId: Int,
@ColumnInfo(name = "user_id") val userId: Int,
)
@Entity
data class User(
@PrimaryKey(autoGenerate = true) val id: Int,
val name: String,
)
When testing it with this
@Test
fun returnsCorrectIds() {
val users = (1..5).map { User(id = 0, name = "User $it") }
userDao.insert(users)
val books = (1..5).map { Book(id = 0, title = "Book $it") }
bookDao.insert(books)
val insertedBooks = bookDao.getAll()
assertThat(insertedBooks).contains(Book(id = 4, title = "Book 4")) // Book 4 has id 4
loanDao.insert(Loan(id = 0, bookId = 4, userId = 2))
val borrowedBooks = bookDao.findBooksBorrowedByNameSync("User 2")
assertThat(borrowedBooks).containsExactly(Book(id = 4, title = "Book 4"))
}
the last assertion here fails:
value of: iterable.onlyElement()
expected: Book(id=4, title=Book 4)
but was : Book(id=2, title=Book 4)
So the Books that are returned all have the User's ID in the id
field. (If Book
had name
instead of a title
it would also return the User's name
as the Book's name
.) If I change the order of the two joins, then the returned Books have the ID of the Loan.
Description
Component used: Room
Version used: 2.4.0-alpha04
Devices/Android versions reproduced on: Pixel 3a emulator
Description:
It's not uncommon to have an
id
column of every database entity. However, the code generated using the new JOIN feature introduced in Room 2.4.0 doesn't have the ability to distinguish betweenid
columns from different entities, which can produce completely wrong results.I've attached a minimal working AS project. In this I've created a
User
and aUserComment
Room entity and attempt to retrieve a list of all Users mapped to theirUserComment
s. But because both entities contain anid
-column, Room gets confused and actually returns a list ofUser
s with ids taken fromUserComment
.As I understand it, differentiating columns with the same name is difficult for Room, but this issue makes the new feature much less useful and downright dangerous given how prevalent the name
id
for the column is.If it's not possible to fix it, perhaps the Room plugin could generate a warning or error if it picks up duplicate column names. As it stands, Room will just silently create faulty data.