Room: @Embedded vs @TypeConverters

user_9867628 0
Viewed 989

If we have @Entity in Room in which there are complex objects as fields, we can use 2 approaches:

@Embedded - as I understand it, if you mark the field with this annotation, then Room will save all the fields that are inside the object as fields of the Entity itself, and then retrieve everything correctly.

@TypeConverters - here we write our own converter, which in most cases boils down to the usual parsing of an object into a Json string.

Actually the question:

What is the fundamental difference? Why not write @Embedded everywhere and not worry about converters? When is it better to write your own converter, and when is it better to use @Embedded, and what are the advantages and disadvantages of these approaches?

android-room kotlin android java
2 Answers

If we have @Entity in Room in which there are complex objects as fields, we can use 2 approaches

Actually there is one more approach to be mentioned here - is saving complex object in separate table and linking to it with foreign key (as usual id with Int or Long type, often autogenerated).

  • If complex object has its own value and has several connections with other objects, consider using separate table and foreign key. Example: You have complex object User and couple of another - UserGroup (and field: user) and Document (field: author). Using separate table User you can change user's name only in one place and you don't need to touch two other tables (but you should do that with @Embedded approach).
  • Widely-used use-case for Type-converter - is converting type Date to integer, since Sqlite doesn't know how to save this type using its own type's system. @Embedded is not helpful in this case.
  • Another widely-used use-case for Type-converter - is persisting in database complex nested structures, often gotten from backend API (JSON serialisation). But this approach is fragile if you later decide to deal with part of these nested structures independently (query to them, for example).
  • One more widely-used (as for my taste - used too much) use-case for Type-converter is persisting List or Array of some objects in one field. But often this approach could be replaced with using separate tables and foreign keys (if these objects form the List have its own value).
  • If in more than one @Entity you use @Embedded on the same complex object it's a sign you should consider option with separate table and foreign key, since it's a waste of space and in some way violation of principles of DB tables' normalisation. For example, if some complex object has N fields and you use it as a @Embedded field at two other tables that means that SQLite generates N additional columns in these two tables.
  • It should be mentioned that @Embedded is widely used in Room's data-classes with @Relation (ROOM's analogues for JOINs). There they are really helpful and help a lot to keep these data-classes' code short and simple. In that way @Embedded doesn't add any duplication to tables' structures (since it affects only on objects in memory) as it does when it's used inside class annotated with @Entity.
user_127184140

The actual difference is, that @TypeConverter uses the same table and @Embedded uses a separate table. Even if @TypeConverter can be abused to serialize/de-serialize JSON, this only makes sense while not needing to query for values in there - but as soon as one wants to query that data, it's a whole lot less effort, when it is backed by an actual table, which one can run SQL against (instead of traversing all records and decoding the JSON). Actually JSON is a data-format, not a data-type.

Just take for example the WordPress post-meta ...this also is JSON stored in an SQL database. Also here it is technically possible, but it's the reason why the performance is below par.

Proper use of a @TypeConverter would eg. be converting from String to BigDecimal.

user_5493720
Related