Room multimap LEFT JOIN nullability [201946438]

Fixed

Bug

Status Update

No update yet.

Description

aa...@gmail.com

created issue #1

Oct 4, 2021 02:36PM

Artifact used : Room Version used: 2.4.0-alpha05 Devices/Android versions reproduced on: Emulator

This is more of a feature request, but trying out the new multimap feature I'm having issues with LEFT JOIN queries.

Take this example from the release notes (One-to-Many relationship):

@Query("SELECT * FROM Artist JOIN Album ON Artist.id = Album.artistId")
fun getArtistAndAlbums(): Map<Artist, List<Album>>

Let's say we want all artists, regardless if they have any albums. So we change the query to use a LEFT JOIN:

@Query("SELECT * FROM Artist LEFT JOIN Album ON Artist.id = Album.artistId")
fun getArtistAndAlbums(): Map<Artist, List<Album>>

This won't work if we have an Artist without albums, if Album doesn't have any nullable fields. Because the current implementation will always try and generate an Album object.

Is it possible to let Room return an empty list of 'Albums' in that case? Or Map<Artist, List<Album>?>?

Thanks for your time!

Comments

au...@google.com <au...@google.com> Oct 6, 2021 08:29PM

Assigned to da...@google.com.

el...@google.com <el...@google.com> #2Oct 6, 2021 09:42PM

Reassigned to el...@google.com.

Project: platform/frameworks/support
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

https://android-review.googlesource.com/1123258

https://goto.google.com/android-sha1/b90079595f33f58fece04026a97faa0d243acdb1

aa...@gmail.com <aa...@gmail.com> #3Oct 11, 2021 10:56AM

The following changes were cherrypicked through Coastguard (

https://android-build.googleplex.com/coastguard/)
Release Track: (

https://android-build.googleplex.com/coastguard/dashboard/6093116828680192/#/cherrypickHistory/all)
Created: 2019-10-14 17:23:42.610596+00:00
Changes: aosp/1123258

el...@google.com <el...@google.com> Nov 4, 2021 12:12AM

Marked as fixed.

ap...@google.com <ap...@google.com> #4Nov 4, 2021 12:13AM

Project: platform/frameworks/support
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 (

b/140759491

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

https://android-review.googlesource.com/1288456

mr...@crossway.org <mr...@crossway.org> #5Dec 2, 2021 08:50PM

What is the expected way of calling the above sample from Kotlin after this fix? Do we need a nullable parameterized type like below?

@Query("SELECT * FROM Artist LEFT JOIN Album ON Artist.id = Album.artistId")
fun getArtistAndAlbums(): Map<Artist, List<Album?>>

I have a database schema similar to the one above, but I am getting a crash on a non-null intrinsics check from the DAO, whether I use a nullable parameterized type or not. I also tried ksp instead of kapt and I am still seeing the same issue.

mr...@crossway.org <mr...@crossway.org> #6Dec 2, 2021 09:51PM

Ah sorry, bad report. After looking at the generated file a bit closer I realized that the problem was a slightly different one. I will file a separate bug report.