Fixed
Status Update
No update yet.
Comments
se...@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?
yb...@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?
yb...@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?
yb...@google.com
It will be maintained, and added to the Room page.
Description
Version used: 1.0.0-alpha8
If I change the order of the member variables within an @Entity Class, I am forced to provide a migration.
Before:
@Entity(tableName = "contacts")
public class ContactEntity {
@PrimaryKey(autoGenerate = true)
private Long id;
@ColumnInfo(name = "phone")
private String phone;
@ColumnInfo(name = "name")
private String name;
@ColumnInfo(name = "mail")
private String mail;
}
After:
@Entity(tableName = "contacts")
public class ContactEntity {
@PrimaryKey(autoGenerate = true)
private Long id;
@ColumnInfo(name = "name")
private String name;
@ColumnInfo(name = "phone")
private String phone;
@ColumnInfo(name = "mail")
private String mail;
}
Is this intended behaviour?
If yes, how would such a migration look like?