Создание таблиц базы данных программно в Evolution King
Представьте себе программу, которая работает с большими иерархическими наборами данных. Программа хранит каждый новый такой набор данных в отдельной таблице. Таблица создается в соответствии с типами данных, которые содержит набор данных. Ну, ничего необычного. Это тривиальная ситуация. Но как мне сделать такие договоренности в Play 2.0, где правила эволюционной парадигмы? Я просто не могу начать думать об этом.
ОБНОВИТЬ
Оказалось, простого пути нет. Хорошо. Круглый путь.
Это возможно:
1) Заставить программу самостоятельно записывать файлы evolutions и применять их автоматически? Не вызовет ли это искажения философии Play?
2) Использовать другую систему БД в отдельном потоке и не использовать врожденную функциональность базы данных Play? Будет ли это больно?
ОБНОВЛЕНИЕ 2
Я читаю документацию MongoDB Casbah и мне это очень нравится. Я планирую использовать это с моим приложением Play. Есть ли какие-либо противопоказания для использования MongoDB через Casbah с Play?
2 ответа
Что ж, после еще нескольких экспериментов я решил использовать MongoDB (на самом деле мне пришлось выбирать из широкого спектра документно-ориентированных СУБД, и я решил начать с MongoDB). Я установил сервер MongoDB, включил его Java-драйвер, Casbah (Scala-оболочку драйвера) и все необходимые зависимости в мой проект, и все работает отлично. Нет нужды в SQL или парадигме эволюции.
И я не использую какие-либо части Play, которые работают с базой данных (файл конфигурации, anorm и что там еще есть), просто игнорирую это и делаю все Mongo.
Все работает просто отлично!
Это хороший вопрос. И нет блестящего ответа, к сожалению.
Как правило, эволюции хороши и желательны, когда вы работаете в группе. В таком случае вам следует переключиться на ручную эволюцию (не сгенерированную Ebean, они опасны для ваших данных в текущем состоянии) и просто увеличить исходный DDL с помощью операторов create.
В следующих версиях вы можете создавать новые таблицы или изменять существующие, но ради бога, не пытайтесь создавать существующие таблицы:)
Другой подход, о котором я думал (или до сих пор), - это использование автоматически сгенерированных DDL Ebean (которое всегда предполагает, что ваша БД пуста) для генерации дифференциальных схем с помощью некоторых инструментов миграции схем SQL (например, mybatis), но, к сожалению, это требует дополнительных усилий.
Последнее, что я иногда использую, когда я не уверен в правильном синтаксисе эволюции, - это небольшое тестовое приложение, где вы можете добавить похожие модели и посмотреть, как плагин Ebean будет угрожать им. К сожалению, даже это решение не создаст правильных изменений, но оно лучше, чем тестирование в основном приложении.