Fixed
Status Update
No update yet.
Comments
ub...@gmail.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?
ba...@gmail.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?
il...@google.com
ap...@google.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?
il...@google.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?
Description
Version used: 1.1.0
Devices/Android versions reproduced on: Emulator API 19
Activity.reportFullyDrawn() was introduced in API 19 but has a bug at that API level requiring the system permission UPDATE_DEVICE_STATS, which is not available to non-system apps. FragmentActivity could override the method and do nothing on API 19 and below. This avoids running into the unfixable bug, and also avoids having to do API-specific code wrapping for API 18 and below where the method does not exist.