Fixed
Status Update
No update yet.
Comments
yb...@google.com
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?
mm...@commonsware.com
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?
de...@gtempaccount.com
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?
sk...@gmail.com
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?
be...@google.com
It will be maintained, and added to the Room page.
yb...@google.com
ap...@google.com
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
Description
Version used: 1.0.0-alpha3
Devices/Android versions reproduced on: n/a
@Relation must return a List<> or Set<>. This includes cases where we know that there should only be one value (e.g., the parent on a 1:N relation). As it stands, we then need to get the 0th entry out of the List or something to get to our one-and-only entity.
IMHO, @Relation should support return types of a single entity instance. If the query returns 2+ rows, I can see three possible responses:
- Throw an exception
- Return the first row's entity
- Either, configurable via an annotation property (and ideally configurable based on build type, as we might throw the exception on debug builds but stagger along with boffo results in production)
After all, in principle, we should have the exact same code ourselves to deal with the current collection-based response.
I'm uncertain how popular @Relation will turn out to be, so I certainly can't characterize this as especially important. I'm just putting it out there for tracking purposes.
Thanks!