Room: @Embedded vs @TypeConverters
Если у нас в Room есть @Entity в которых в качестве полей есть сложные объекты мы можем использовать 2 подхода:
@Embedded - как я понимаю, если пометить поле этой анноташкой, то Room все поля которые находятся внутри объекта сохранит как поля самой Entity, а потом извлечет все корректно.
@TypeConverters - тут мы пишем свой конвертер, который в большинстве случае сводится к обычному парсингу объекта в Json строку.
Собственно вопрос:
В чем принципиальная разница? Почему бы не писать везде @Embedded и не париться о всяких конверторах? Когда лучше писать свой конвертор, а когда лучше использловать @Embedded, и какие преимущества и недостатки дают эти подходы?
Ответы (2 шт):
@Embedded можно повесить лишь на конкретное поле/свойство, @TypeConverters помимо полей, можно повесить на Dao, Entity, БД (будут конвертиться все объекты подходящего типа в Dao, всей Entity, во всех Entity в БД соответственно). К тому же не на все типы получится использовать Embedded, например коллекции.
Помимо @Embedded и @TypeConverters, нужно еще не забывать о @Relation. Если бездумно использовать @Embedded то придется потом перелопатить всю таблицу. К примеру есть у нас User, внутри он содержит Address. Мы пометили его как @Embedded и room запишет все в одну таблицу. И тут надо нам добавить еще один адрес, и все @Embedded уже теряет актуальность. Так как его нельзя повесить на коллекцию. Тут стоит уже использовать связи. Еще один недостаток, это то что таблица становится слишком перегруженной. И будет хранить данные совсем разного толка, адреса, данные пользователей, марку его машины и так далее. Это в дальнейшем может выстрелить в ногу.
Что по поводу @TypeConverters. Я думаю он хорош если у вас вложенный список примитивов. Если конвертировать объекты, допустим с помощью Gson, в дальнейшем будет сложно осуществить выборку по какому-то из них. Допустим взять того же User со списком адресов. У адресов есть номер дома, индекс и так далее. Сковертируем мы это в Json. Запишем. Дальше нам понадобится найти юзера по индексу. Искать в json строках намного дороже чем искать обычный int.
По итогу все сводится к тому, как нам потом придется искать что-то в этих данных и придется ли вообще.