Pull to refresh

Comments 11

интересно как вы тащите сущности из таблицы, в которой мноого записей используя пресловутый статический метод getAllEntities без условий на выборку (ну например для пейджинга по таблице с фильтрами и группировками)? Тут напрашивается свой парсер критериев выборки (свой язык в общем-то) имхо (ну не where лепить же, который зависимый от конкретной субд)…
Ну, конечно нет. getAllEntities это только один из примеров. Хотя отчетами еще не занимался, и в полноценном where смысла пока не было, но сейчас еще как минимум есть getEntityByKeyValue и getEntitiesByParent. Думаю, по поводу первой функции и так все ясно, а вот вторая принимает на вход, например, экземпляр Car, а возвращает все связанные с ним Wheels. Тут опять же, еще не универсально, так как пока у меня нет сущностей содержащих несколько связанных списков. Where же хочу реализовать в стиле Android (как, например AlertDialog.Builder), то есть каждый его оператор будет возвращать все тот же конструктор. Что-то типа этого:
Car.Where().Equils(”engine_power”, 169).And().Equils(“doors_count”, 5).Select();

В свое время тоже делал для себя клон ActiveAndroid, но не ушел достаточно далеко :)
В настоящих приложениях реальную проблему представляют собой миграции схемы при обновлениях.
Да. Я обновлениями пока тоже не занимался, хотя и предусмотрел onUpgrade в Helper’е. На самом деле, orm составляет только лишь 30% от моего проекта, это, так сказать, сопутствующая вещь. А посему и хочу сделать его открытым, вот только код причешу немного.
При желании хранить сущности-наследники одного класса с большой вариацией наборов полей я бы выбрал документно-ориентированную бд. Сразу скажу, что не знаю, как с этим у Андроида.
Нативно Android поддерживает только SQLite. И хотя цепляться к удаленным базам проблем не составляет (пробовал к MySQL установленной на сервере – все хорошо), установить другой движок БД именно на устройство, думаю, будет весьма проблематично. Плюс, работал с XML в Oracle, вроде все отлично: и преобразования есть, и валидация, и XPath поддерживается в полной мере. Но, как только записей с XML данным внутри которых необходимо провести поиск переваливает хотя бы за 1k, время запроса увеличивается в разы. Пришлось городить огород из дополнительных таблиц для поиска. Хотя, возможно, это из-за того, что изначально Oracle не документо-ориентированная СУБД.
А что мешает тащить любую embedded database (будь то NoSQL, key-value, whatever) в виде нативных бинарников под нужные архитектуры?
И распирать apk-файл до десятка мегабайт? Я уже получил проблему в самом приложении, оттого, что в Google не реализовали SchemaFactory, и провести валидацию XML без сторонних библиотек не получается. Библиотек Xerces же, увеличивает apk на 2.2 Мб! Пришлось писать свою валидацию (без поддержи xsd, разумеется). Плюс, сама SQLite меня совершенно устраивает.
Если у Вас жесткие ограничения на размер apk, тогда понятно. Просто заявление «установить другой движок БД… проблематично» — очень уж сильное :)
Ограничения конечно не жесткие, но факт – остается фактом. Хотя с «проблематично», я может быть слегка и погорячился.
Думаю, что самопальная сборка какого бы то ни было хранилища на неподдерживаемой платформе может вылиться в те ещё баги. Хотя, опять же, я не спец по Андроиду.
Sign up to leave a comment.

Articles