AnnotatedSQL lib — автоматическая генерация базы данных в Android

[@VashS]

Хорошая библиотека. Для IDE NetBeans — Annotation Processors может пригодиться для справки.

[@knott]

Все будет хорошо до первого апгрейда схемы базы данных.

[@hamsterksu]

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

[@hamsterksu]

а чего сразу минус? :) а по существу — если приложение синкается с сервером, то сохранив креденшелы или аксес токен в перференсы можно спокойно закилить базу и синкнуть ее. конечтно если там не сильно много данных.
например такое точно подходит для всяких там рсс и прочего тонкого клиента.

[@knott]

Ну не плюс это точно.

А если придумать механизм апдейта схемы, то и загружать ничего не придется.

[@hamsterksu]

Идеи в студию.

Первый вариант: Вводим аннотацию version и помечаем поля, но это геморно.

Второй вариант: сравнивать наборы полей таблиц — той что в базе и новой. Так сможем отследить добавление, удаление и изменение типа колонок, но переименование колонки не отследить

[@vladlichonos]

Было бы вообще прекрасно если бы вот эта часть тоже генерировалась, так как то, что сейчас, не лучший вариант

Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { SqlSchema.onDrop(db); onCreate(db); }

[@hamsterksu]

У меня не ORM, а чистой воды хелпер.
Сам я не юзал ORMLite, но знакомые говорят, что юзать его с CursorAdapter и контент провайдером не реально. Это так?

[@isolda]

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

[@hamsterksu]

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

[@isolda]

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

А.
— Пишем SQL-код
— Запускаем, видим результат и ошибки
— Повторяем

Б.
— Пишем Java-код с аннотациями (раза в 2 больше по объему)
— Компилируем
— Запускаем
— Берем полученный файл, добавляем в приложение, компилируем
— Запускаем, видим результат и ошибки
— Повторяем

Если в варианте «Б» что-то вышло не так, то придется восстановить в голове обратную цепочку и понять, что же нужно исправить в исходных аннотациях, чтобы получился нужный SQL.

[@hamsterksu]

Стоять.

Вы всеравно пишите описание таблички в интерфейсе или классе. Вам нужны константы с именами полей и таблицы. Все что нужно — это вместо SQL развесить аннотации.

Копировать файлы не надо. Он сгенерится в вашем проэкте в папке gen там где и файлик R.java

Что за пункт «компилируем» в «Б»? Как только вы сохранили изменения — файл перегенерился

Так что никаких лишних степов не будет.

[@hamsterksu]

Как удалить коммент?

[@evilduck]

Почитал комментарии. «Налицо усложненный микро-цикл», «налицо проблемы». Я использовал эту либу в проекте с более-менее развесистой структурой БД и провайдером. Налицо то, что я потратил 20 минут на то, чтобы описать интерфейсы с аннотациями и после этого получил готовую схему, готовый провайдер с кучей рутины и дополнительных плюшек. И все это получил сразу. Писать руками такой провайдер заняло бы пару часов, а тут он вот, готовый.
С обновлениями проблем особых также не возникало. В процессе разработки вы делаете готовую базу. Потом, когда приложение в продакшне, вы точно так же обновляете описание, и добавляете обновление в onUpdate. При этом, провайдер «пофиксится сам». По сути эта библиотека облегчает Вам процесс создания БД и провайдера. В остальном- полная свобода. Процесс ее обновления остается таким же, как и без нее. Но это не проблема.
И при чем тут ORMLite? Цель этой библиотеки — ускорить и облегчить процесс создания базы, а не навернуть на нее так любимый начинающими «ОРМ это же круто, у нас объекты, а не курсор».