Je pense que la meilleure façon de répondre à cette question est un bref aperçu des structures de stockage...
Listes
Room ne prend pas en charge le stockage de listes imbriquées à l'intérieur d'un POJO. La façon recommandée de stocker des listes est d'utiliser l'approche de la clé étrangère. Stockez la liste des objets dans une table séparée (dans ce cas, une table smallObjects) avec une clé étrangère vers leur objet parent (dans ce cas, "big_object_id"). Cela devrait ressembler à quelque chose comme ceci...
@Entity
public class BigObject {
@PrimaryKey
private int id;
private User user;
@Ignore
private List<SmallObject> smallObjects;
}
@Entity(foreignKeys = {
@ForeignKey(
entity = BigObject.class,
parentColumns = "id",
childColumns = "big_object_fk"
)})
public class SmallObject {
@PrimaryKey (autoGenerate = true)
private int id;
private String smallValue;
@ColumnInfo(name = "big_object_fk")
private int bigObjectIdFk
}
Notez que nous avons ajouté le @Ignore
annotaiton à List<SmallObject>
car nous voulons ignorer le champ pendant la persistance de la pièce (les listes n'étant pas prises en charge). Il existe maintenant pour que, lorsque nous demandons notre liste de petits objets connexes à la base de données, nous puissions toujours les stocker dans le POJO.
À ma connaissance, cela signifie que vous effectuez deux requêtes.
BigObject b = db.BigObjectDao.findById(bOId);
List<SmallObject> s = db.smallObjectDao.findAllSOforBO(bOId);
b.setsmallObjects(s);
Il semble qu'il existe un raccourci pour cela sous la forme de @Relation
Convertisseurs de type
Ils sont destinés aux cas où vous disposez d'une structure de données complexe qui peut être aplatie sans perdre d'informations et stockée dans une seule colonne. L'objet Date en est un bon exemple. Un objet Date est complexe et contient un grand nombre de valeurs. Son stockage dans la base de données est donc délicat. Nous utilisons un convertisseur de type pour extraire la représentation en millisecondes d'un objet date et la stocker. Nous convertissons ensuite les millisecondes en objet date à la sortie, ce qui permet de conserver nos données intactes.
Embarqué
Ceci est utilisé lorsque vous voulez prendre les champs de toutes les POJO imbriquées dans votre POJO parent et les aplatir pour les stocker dans une table. un exemple :
- name
- age
- location
- x
- y
- DOB
lorsqu'elle est intégrée, cette structure est stockée dans la base de données sous la forme d'un fichier :
- name
- age
- location_x
- location_y
- DOB
Dans un sens, Embedded existe pour vous faire gagner du temps en créant des convertisseurs de type pour chaque objet imbriqué qui contient des champs de type primaire comme String, int, float, etc....
2 votes
En général, les entités ne détiennent pas d'autres entités en chambre, que ce soit individuellement ou sous forme de listes. Elles peuvent détenir clés étrangères à d'autres entités. D'autres structures, comme un modèle de vue, peuvent contenir toutes les entités nécessaires. C'est ainsi qu'il faut procéder,
BigObject
doit se débarrasser desmallObjects
et remplaceruser
conuserId
comme clé étrangère.User
ySmallObject
aurait des clés étrangères versBigObject
. Ensuite, mettez en place un modèle de vue ou quelque chose que vous alimentez à partir de@Query
Les méthodes DAO qui récupèrent lesBigObject
et ses liens avec d'autres paysUser
et de ses liens avec d'autresSmallObjects
.