Кто шарит в Room? Есть ли способ как-то добавить в

реализацию интерфейсов @Dao, которая генерируется автоматически, свой код? Конкретно идея в том, чтобы кроме заполнения списка записей на основе select’а, нужно еще некоторые дополнительные поля списка заполнить не из базы.

я бы писал классы поверх где есть поля не из базы. хз

Не понял смысла этого. Если нужно что-то еще заполнить, то делайте вызов метода, который это умеет(написанный вами в дао)

Дао отвечает только за работу с румом, ни более

Получается лишний проход, сначала сгенерированный код пробегает курсором все записи и заполняет список, потом мой метод опять пробегает все записи уже заполненного списка и дозаполняет его. Я из ++ пришел в мобильную разработку, мне кажется это неоптимально.

Посмотри в самом внизу есть direct cursos access, мб это то, что тебе нужно https://developer.android.com/training/data-storage/room/accessing-data

Ну тогда вам смотреть в сторону чистого OpenDBHelper(или как там его) без абстракций

да. я видел, там еще какая-то плашка страшная с предупреждением меня пугает.

А почему бы не выстроить код так, чтобы в один проход создавался элемент со всеми значениями?

Похоже на то. Просто везде хвалят и одобряют только Room, решил осваивать как рекомендуют. С другой стороны наверное реально такой функционал добавить в room , который генерил бы код с добавкой юзерской вставки. Теже TypeConverter существуют .

Room хвалят и все используют, чтобы код был попроще и видеть поменьше внутренностей работы с SQL. Под капотом там тот же OpenDBHelper, если не ошибаюсь.

+ поддержка корутин и Rx из коробки

Конкретно мне нужно считать из базы данных записи где есть поле даты+время, и пометить записи которые соответсвуют первому дню года, месяца и дня соответсвующей пометкой в отдельном поле.

Ну т.е. на основе уже существующих в БД данных? Можно либо вычислить остальное перед добавлением, либо лучше нормальный второй проход по базе с добавлением

Ну вот пример я добавляю в базу дату 10 июня, и она первая за июнь. ставлю пометку и сохраняю в б.д. потом мне вдруг приходится добавить запись за 9 июня, и значит она уже первая будет и значит надо снять пометку с предыдущей - звучит бредово. так же как бредово обновлять всю базу после каждого добавления изменения удаления.

А вы хотели, чтобы пометка с записи за 10 июня волшебным образом исчезла при добавлении записи за 9 июня?) Или 2 селекта делать не хочется?

Update db record, не? Сортировка ещё есть... Селекты всякие...

Не совсем. Изначально есть список на экране с записями считанными из массива, который считался через room из базы. юзер добавляет запись, делается новый запрос к базе, который заполняет массив и через уведомление от livdata перерисовывается список. Если не хранить пометки, то они легко на лету вычисляются проходом по отсортированному по дате массиву путем сравнения даты в текущей и предыдущей записи. Вот я и подумал что можно эти пометки вычислять в room на этапе загрузки записей, а не отдельным проходом по массиву.

Что такое пометки в вашем случае?

поле целого типа например или логическое. просто чтобы можно было бы пометить запись в списке особым образом, и вывести сумму за месяц, год и т.п. для юзера.

Если ваши пометки влияют лишь на порядок записей на экране, то лучше их вообще не иметь в базе для сортировки, а использовать дату или что-то еще.

Они влияют не на порядок, а на видимость заголовков для групп отображающих сумму за год, месяц, день в списке на базе recyclerview. Т.е. если запись (при обработке адаптере) имеет пометку первая за месяц, то я делаю видимыми заголовок за месяц.

Есть наверное другие способы отобразить заголовки групп, генерируя массивы в которых для заголовка отдельная запись, но мне хочется сократить лишние вычисления и использование памяти.

Тогда при добавлении новой записи сделайте поиск, который определит, является ли запись первой. Если да, то ставьте ей метку и, если у какой-то более поздней записи она уже есть, то убирайте ее отдельным запросом. Я очень сомневаюсь, что это как-то ухудшит производительность.

Это конечно сработает, но усложняет всю схему, с учетом того что записи могут собираться с нескольких мобил через базу в инете с последующей синхронизацией, то проще вычислять на лету, чем при добавлении.

Ну тут уже решение за вами. Потестируйте несколько сценариев и выберите тот, который лучше справляться будет.

Это да.. спасибо за советы.

Тогда есть риск, что в одной базе будет одно состояние данных, в другой - другое 🤔

После синхронизации у всех будет одно состояние до очередного добавления, врЕменное расхождение не критично, критична скорость работы интерфейса и затраты памяти устройства.

Скорее всего придется искать компромиссные решения. Производительность бд на мобилках не очень.

На моем редми4 про все летает на 100к записей

Было бы полезно на разных девайсах погонять.

625?

не понял, че за число?

snapdragon 625?

наверное, уже не помню. когда покупал писали что очень удачная моделька