Fixed
Status Update
Comments
ma...@google.com <ma...@google.com>
as...@google.com <as...@google.com> #2
Actually that was an experimental API we thought about removing a couple of times but decided to keep for now.
About 1-1, it is actually better to write them as join queries. Is there a case where join is not feasible?
About 1-1, it is actually better to write them as join queries. Is there a case where join is not feasible?
br...@monzo.com <br...@monzo.com> #3
The issue with a JOIN is not feasibility. I suspect that can be done, albeit at the cost of yet another non-entity POJO.
Let's flip it around: given your characterization of the origins of @Relation ("an experimental API") and its possible lame-duck status ("decided to keep for now"), should we be using it?
Let's flip it around: given your characterization of the origins of @Relation ("an experimental API") and its possible lame-duck status ("decided to keep for now"), should we be using it?
as...@google.com <as...@google.com> #4
How would I load all the relation objects immediately without a relation? I see in your documentation that you have a query like "@Query("SELECT user.name AS userName, pet.name AS petName "
+ "FROM user, pet "
+ "WHEREuser.id = pet.user_id")
public LiveData<List<UserPet>> loadUserAndPetNames();", but how would you load complete objects with it, not just certain fields? I tried using something like "SELECT * , * as comments FROM users, comments", but it was throwing an error?
+ "FROM user, pet "
+ "WHERE
public LiveData<List<UserPet>> loadUserAndPetNames();", but how would you load complete objects with it, not just certain fields? I tried using something like "SELECT * , * as comments FROM users, comments", but it was throwing an error?
br...@monzo.com <br...@monzo.com> #5
I'm interested in this feature along with the ability to use a projection like "[expression] AS [column-name]" and map to a single value. Additionally, since the @Relation annotation is never mentioned on the Room page, will it be maintained?
ap...@google.com <ap...@google.com> #6
It will be maintained, and added to the Room page.
br...@monzo.com <br...@monzo.com> #7
Project: platform/frameworks/support
Branch: androidx-master-dev
commit c5dad6522e6c20bbd5ca8e53b8406a94cb84cfe8
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Wed Jun 12 16:43:53 2019
Allow single-value @Relation field.
This change lifts the restriction of @Relation annotated fields needing
to be List or Set allowing for a more seamless representation of a
one-to-one relationship.
Changes in the generated code is so that it is not always assumed that
the relation field is a collection, thus not needing a temporary
collection when collecting the relating objects.
Bug: 62905145
Test: ./gradlew room:room-compiler:test \
room:integration-tests:room-testapp:cC
Change-Id: I462d59e89b55c43842df43cb84c1aeca0b2b743e
M room/common/src/main/java/androidx/room/Relation.java
M room/compiler/src/main/kotlin/androidx/room/processor/PojoProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/processor/ProcessorErrors.kt
M room/compiler/src/main/kotlin/androidx/room/vo/RelationCollector.kt
M room/compiler/src/main/kotlin/androidx/room/writer/RelationCollectorMethodWriter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/PojoProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/dao/PetDao.java
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/PojoWithRelationTest.java
A room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/vo/PetAndOwner.java
https://android-review.googlesource.com/982373
https://goto.google.com/android-sha1/c5dad6522e6c20bbd5ca8e53b8406a94cb84cfe8
Branch: androidx-master-dev
commit c5dad6522e6c20bbd5ca8e53b8406a94cb84cfe8
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Wed Jun 12 16:43:53 2019
Allow single-value @Relation field.
This change lifts the restriction of @Relation annotated fields needing
to be List or Set allowing for a more seamless representation of a
one-to-one relationship.
Changes in the generated code is so that it is not always assumed that
the relation field is a collection, thus not needing a temporary
collection when collecting the relating objects.
Bug: 62905145
Test: ./gradlew room:room-compiler:test \
room:integration-tests:room-testapp:cC
Change-Id: I462d59e89b55c43842df43cb84c1aeca0b2b743e
M room/common/src/main/java/androidx/room/Relation.java
M room/compiler/src/main/kotlin/androidx/room/processor/PojoProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/processor/ProcessorErrors.kt
M room/compiler/src/main/kotlin/androidx/room/vo/RelationCollector.kt
M room/compiler/src/main/kotlin/androidx/room/writer/RelationCollectorMethodWriter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/PojoProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/dao/PetDao.java
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/PojoWithRelationTest.java
A room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/vo/PetAndOwner.java
na...@google.com <na...@google.com> #8
The following release(s) address this bug:
androidx.compose.runtime:runtime:1.3.0
Description
Jetpack Compose version: I've tested on 1.3.0-alpha01 and 1.2.0-beta03
Jetpack Compose component(s) used: LazyColumn
Android Studio Build: 221.3427.89.2211.8689873
Kotlin version: 1.7.10
Steps to Reproduce or Code Sample to Reproduce:
Context:
We have a rather large (10k+ items) LazyColumn where scrolling (eventually) leads to the application grinding to a halt, constantly trying to free memory. It can't, we just keep getting lots of these:
Background concurrent copying GC freed 51964(1414KB) AllocSpace objects, 6(120KB) LOS objects, 0% free, 190MB/192MB, paused 101us total 1.483s
I took at heap dump at this point and basically all of the heap is used up by instances of
SnapshotMutableStateImpl$StateStateRecord
.Replace LazyColumn with a RecyclerView (with each item being a ComposeView) and the memory leak is gone. App performance is night and day better.
I've been trying for hours to reproduce this in a trivial sample project and haven't had any luck yet. Raising this anyway just in case you have any ideas about what might be causing it. Obviously this makes LazyColumn completely unusable for us, so we'll stick to RecyclerView for now!