Что в ORM тебе моем? Околонаучный подход выбора ORM для Android

[xGromMx]

На этот проект не смотрели realm.io?

[nemezis]

Смотрели, отпугивает размер библиотеки и закрытость кода самой базы данных (доступны исходники только оберток).

[demand]

Разве закрыты? На GitHub лежат все исходники библиотеки, просто ядро на C++ (NDK).

[nemezis]

Исходный C++ код просмотрел мельком, смутили такие include

#include <tightdb/group_shared.hpp>
#include <tightdb/replication.hpp>
#include <tightdb/commit_log.hpp>

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

[Ghedeon]

Поддерживаю вопрос. Хотелось бы увидеть realm в отчете, для полноты картины.

[andreich]

Realm — nosql база данных. Это конечно ничего, но вот отсутствие поддержки primary key меня остановило на половине пути внедрения.

[akira]

github.com/realm/realm-java/pull/565
Другой вопрос, что для боевого применения его все еще рано использовать, иногда просто падает сам движок, мы попробовали наше приложение и при наличии определенных данных движок скисал, причем не только в телефоне, но и в их браузере.

[AlexBonel]

Разве это реляционная БД? Все-таки парадигма-то не одна и та же. В статье автор рассматривает использование ORM для реляционных баз данных.

Мне гораздо интереснее было бы, если бы вы еще Cupboard попробовали и поделились своим мнением.

[akira]

Для большинства приложений реляционная БД и не нужна.

[Mecid]

Вот мой набор для работы с БД.
cupboard — bitbucket.org/qbusict/cupboard
provigen — github.com/TimotheeJeannin/ProviGen

[dougrinch]

Я вот чего не понимаю, а зачем вообще БД? У нас же не серверное приложение, которому действительно нужно хранить много разных данных. Я писал клиенты (не под android), и ни разу не понадобилась БД. Просто хранишь все в памяти, если нужны новые данные — запрашиваешь с сервера. Это именно какая-то android-специфика?

[nemezis]

Мобильные клиенты используют БД как кэш, чтобы обеспечить работу приложения без интернета. Особенно это актуально для Android где приложение может быть выгружено из памяти в любой момент. Согласитесь, что гораздо приятнее смотреть на кэшированные данные, чем на сообщение об ошибке.

[dougrinch]

Просто если это рантайм-кеш, то все равно без бд проще. Ничего лишнего, хранишь сразу как тебе удобно. А вот в условиях «приложение может быть выгружено из памяти в любой момент», действительно оптимальна локальная бд. Спасибо за разъяснения.

[FractalizeR]

Ничего лишнего, хранишь сразу как тебе удобно.

Я думаю, что в основном удобно как раз в БД хранить, чем изобретать и дебажить свои велосипедные, быстро усложняющиеся со временем форматы данных, поверх которых медленно прикручиваются самодельные индексы для ускорения поиска, самопальные DQL для удобства поиска и так далее.

[RouR]

Логично поместить кешированные данные в файлы кэша.

[alexzzam]

И организовать эти файлы как базу данных для удобства доступа. Например, SQLite отличное решение для хранения всего в файле… И, внезапно, стандартное для Android.

[beono]

Например, приложение для учета финансов с различными отчетами (без серверной части).

[kemsky]

Можно попробовать настройки SQLite (cache_size и journal_mode), на андроиде их наверное можно задать через #pragma. Ускорите и чтение и запись соответственно.
Кроме того в SQLite insert поддерживает множественную вставку (INSERT INTO Table ( Column1, Column2 ) VALUES( Value1, Value2 ), ( Value1, Value2 )) — тоже можно оптимизировать на уровне ORM (сумеет ли андроид — другой вопрос).
Еще интересно, что за данные вы писали(40-20 сек это достаточно много).

[nemezis]

Попробовать настройки SQLite и множественный insert действительно интересно, стоит провести эксперимент. Спасибо за совет.

Список о котором идет речь в статье (который сохранялся 40 секунд) состоял из 10 полей, одно из которых было ссылочным полем на другую сущность. Список состоял примерно из 500 объектов.

[kivsiak]

Чет тут не так. Можно код посмотреть?

[Norraxx]

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

[nemezis]

Ответил в личку

[nemezis]

Код сохранения списка до оптимизации:

if (response.isSuccessful()) {
    try {
        ActiveAndroid.beginTransaction();
        ArrayList<Deputy> deputies = new ArrayList<Deputy>();
        JSONArray array = response.getData().getJSONArray("deputat_list");
        for (int i = 0; i < array.length(); ++i) {
            Deputy deputy = Deputy.fromJSON(array.getJSONObject(i));
            deputy.save();
            deputies.add(deputy);
        }
        this.deputies = deputies;
        DeputiesConnections.setRelationsF(DeputiesConnections.class, DeputiesList.this, deputies);
        ActiveAndroid.setTransactionSuccessful();
        return ERROR_NOT_SET;
    } catch (Exception e) {
        Log.e("Cannot parse deputies list", e);
        return ERROR_UNKNOWN;
    } finally {
        ActiveAndroid.endTransaction();
    }
}

Код сохранения списка после введения оптимизации:

if (response.isSuccessful()) {
    try {
        ActiveAndroid.beginTransaction();
        ArrayList<Deputy> deputies = new ArrayList<Deputy>();
        JSONArray array = response.getData().getJSONArray("deputat_list");
        for (int i = 0; i < array.length(); ++i) {
            Deputy deputy = Deputy.fromJSON(array.getJSONObject(i));
            deputies.add(deputy);
        }
        Deputy.saveMultiple(deputies);
        this.deputies = deputies;
        DeputiesConnections.setRelationsF(DeputiesConnections.class, DeputiesList.this, deputies);
        ActiveAndroid.setTransactionSuccessful();
        return ERROR_NOT_SET;
    } catch (Exception e) {
        Log.e("Cannot parse deputies list", e);
        return ERROR_UNKNOWN;
    } finally {
        ActiveAndroid.endTransaction();
    }
}

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

[AntonRychagov]

Скрытый текст

[nemezis]

Ответил в личку

[nemezis]

см. выше

[stepango]

На maven/jcenter планируете выложить?

[sapl]

Подскажите
пожалуйста сколько по времени миллисекунд выполняется коннект к базе
и первый запрос данных с нулевого старта приложения?

[Scogun]

Большое спасибо за такое нужное приложение! Вкрячил в него свой велосипед, который, ожидаемо, оказался худшим. Буду стараться обойти хотя бы Sugar ORM.

[Scogun]

Хм, переделал работу с транзакцией: перегнал по записи не только Sugar ORM и ActiveAndroid, но и ORMLite. Теперь вот чтение…

[ncix]

Тест производительности слишком тепличный.
Сам однажды наступил на подобные грабли. Делали некую ORM-прослойку на основе генерации SQL-запросов «на лету». Когда речь шла про отдельные таблицы и простейшие CRUD-запросы, все было великолепно. Когда понадобились связанные таблицы и ссылочные поля — генерация запросов усложнилась в разы (что пришлось долго отлаживать и чинить), производительность упала из-за невозможности всегда сгенерить оптимальный запрос в конкретной ситуации.
Когда дошло до сложных выборок — тут объем необходимого высокоуровнего кода стал резко превышать сложность генерируемого внутри SQL-запроса. Т.е. такие задачи проще было бы решать без этой прослойки. Да вот незадача — следующий уровень абстракции уже был заточен на ORM.

Но справедливости ради, думаю в Android подобных сложных кейсов быть не должно.

[Norraxx]

Когда-то наступил на грабли, решая на андроиде всё как на сервере, при работе с базой данных. Это принесло очень много неудобств и ограничений.
Сейчас одна таблица аля: запрос, немного другой инфы и JSON. Результат на лицо: всё работает в разы быстрее и приятнее.
Итог: на сервере подготавливать всё наперёд, а андроид — он хоть и сильный, но служит в большинстве случаев, для отображения данных.