- Support for multimap return types in @Dao methods, useful for JOIN statements, including Map and Guava's ImmutableMap, ImmutableSetMultimap and ImmutableListMultimap
- Multimap query results can be wrapped in async return types such as LiveData, Rx Observable, or coroutines Flow
- New androidx.room:room-paging artifact providing native Paging 3.0 support for Room queries returning androidx.paging.PagingSource
- The room-paging PagingSource implementation parses keys differently, and pages now start loading from the Key as the first loaded item instead of treating LoadParams.Refresh.Key as the scroll position with items loaded both before and after the key
- Fixed an issue in auto migrations regarding handling of foreign key violations
From Room
Room now supports multimap return types @Dao methods, useful for JOIN statements. The supported types of multimaps are Map along with Guava's ImmutableMap, ImmutableSetMultimap and ImmutableListMultimap. The following are examples of multimap queries: One-to-One Relation Map @Query ( "SELECT * FROM Song JOIN Artist ON Song.artistId = Artist.artistId" ) fun getSongAndArtist (): Map<Song , Artist> One-to-Many Relation Map (Standard multimap) @Query ( "SELECT * FROM Artist JOIN Album ON Artist.id = Album.artistId" ) fun getArtistAndAlbums (): Map<Artist , List> The multimap result can also be wrapped in the supported async return types, such as LiveData, Rx’s Observable, or coroutines Flow. Note: In version 2.4.0-alpha04, only multimaps with POJOs as type parameters are supported, but in a future version String and primitives will also be supported. Room-Paging androidx.room:room-paging is released, providing native Paging 3.0 support for Room queries returning androidx.paging.PagingSource. @Dao interface UserDao { @Query ( "SELECT * FROM users ORDER BY id ASC" ) fun loadUsers (): PagingSource<Int , User> } This artifact replaces the androidx.paging.PagingSource implementation generated by Room with one built on top of Paging 3.0 APIs. The new PagingSource implementation parses keys differently, so any key manually supplied to Room’s PagingSource would need to account for this behavior change, including the initialKey passed via Pager’s constructor. Pages will start loading from the Key with Key being the first loaded item. This deviates from existing behavior where LoadParams.Refresh.Key is treated as the user's scroll position and items are loaded both before and after the key. The artifact is optional and opting out will fallback to existing support for Paging 3.0 that was introduced in Room 2.3. However, this artifact will become non-optional in future release for those using Room with Paging 3.0. To opt-in, add the new room-paging artifact to your classpath. If you are using Gradle, you can add the following snippet to your build.gradle: dependency { implementation ( "androidx.room:room-paging:2.4.0-alpha04" ) } Fix an issue in auto migrations regarding handling foreign key violations. ( b/190113935)