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.

A couple of questions:

1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?

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

Tested on Android 12 Emulator with custom executor, but cannot repro this issue.

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

Second crash in the description is from a real device. Experienced it myself on two different Xiaomi phones, plus lots of crashes from users in the Google Play console.
Dynamic features are not used in the application.

As a wild guess, I have downgraded build tools from 31.0.0 to 30.0.3, compileSdk from 31 to 30, and moved all work with Language ID to the service in a separate process (just to be sure that crash can kill secondary process instead of main). This combination is in beta for 2 days by now and I don't see any SIGSEGV crashes.

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

Hmm, I feel the crash might be something related to separate/secondary process.

I also changed compileSdk and targetSDK to 31 but still cannot repro this issue.

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

On the contrary, there was no separate process before, when crashes started.

In the new build (with the aforementioned changes) I can see SIGSEGV crash, but only one instead of dozens and it has a bit different backtrace:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
liblanguage_id_jni.so (offset 0x11e000)

backtrace:
  #00  pc 000000000003c7c0  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003b960  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bb48  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bafc  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000036c98  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000032714  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000031cac  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000057438  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/oat/arm64/base.odex (offset 0x57000)