Play framework с начальной вставкой JPA

Question

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

В моем случае у меня есть класс сущности «Studycourse». Все таблицы создаются через JPA при первом запуске.

Я использую эволюцию DB (1.sql) для вставки данных по умолчанию, например .:

INSERT INTO studycourse (id, title) VALUES (1, 'Computer Science'); 

Это работает при использовании команды нормальной «активатор запуска». Но если я «тест-активатор» и начать простой тест интеграции с inMemoryDatabase(), я получаю следующее сообщение об ошибке:

[error] play - Table "STUDYCOURSE" not found; SQL statement: INSERT INTO studycourse (id, title) VALUES (1, 'Computer Science') 

Я думаю, что начальная настройка JPA не выполняется в БД в оперативной памяти.

Вопрос: Есть ли наилучшая практика в отношении того, как это сделать?

Тест интеграции выглядит следующим образом:

public class IntegrationTest { 
    @Test 
    public void test() { 
     running(testServer(3333, fakeApplication(inMemoryDatabase())), HTMLUNIT, new Callback<TestBrowser>() { 
      public void invoke(TestBrowser browser) { 
       browser.goTo("http://localhost:3333"); 
       assertThat(browser.pageSource()).contains("Your new application is ready."); 
      } 
     }); 
    } 
} 

Спасибо заранее.

Answer 1

Ваш первоначальный вопрос по существу задал вопрос: «Как выполнить шаги инициализации JPA в тестовой среде, чтобы моя база данных в памяти была заполнена, когда я запускал тесты интеграции с моей базой данных?».

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

Моя интерпретация ваших целей является то, что вы хотите:

• Создать хорошую практику для миграции схемы базы данных
• Создание общей практики для интеграции баз данных тестирования

схемы базы данных миграции

Как я уже упоминал в своем комментарии выше, мы используем http://flywaydb.org для миграции схемы базы данных, и это был выдающийся инструмент. У Flyway есть плагин SBT, поэтому вы можете запускать flywayClean и flywayMigrate прямо с activator, чтобы мгновенно удалить и повторно инициализировать вашу базу данных.

Flyway поддерживает сложные версии имен файлов, так что вы можете выполнять SQL-скрипты, такие как v1.1.0.sql, v1.1.1.sql и v1.2.0.sql. Flyway также будет жаловаться, если вы попытаетесь выполнить сценарии миграции, которые не являются чистым улучшением существующего состояния базы данных. Это означает, что мы используем пролетный путь для переноса миграции схемы базы данных в производство, уверенно полагая, что это провалится, если мы сделаем что-то глупое. Конечно, мы всегда берем резервную копию БД прямо перед миграцией только для того, чтобы быть в безопасности.

Наконец, Flyway позволит вам запускать java-программы для заполнения базы данных, если вы хотите использовать сервисные методы вместо простого SQL-кода.

В любом случае, ваш выбор здесь в основном играет эволюции, пролет или Liquibase.

In-Memory Database против Dev-Database

По этому вопросу я видел две основные позиции:

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

2. Используйте базу данных в памяти для loca l, но, по крайней мере, ваш сервер сборки использует базу данных dev.

Вы можете увидеть, например, комментарии в конце http://blog.jooq.org/2014/06/26/stop-unit-testing-database-code/.

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

Вариант №2 дает вам чуть более низкую скорость в целом, но дает вам немедленную обратную связь по реальной базе данных.

Как и в большинстве случаев в технике, нет «лучшего» решения, просто набор компромиссов, которые имеют наибольший смысл для вашей команды.

Выбор ORM слоя

Сначала мы начали с Hibernate, но в конце концов перешел на http://jooq.org. См. http://www.vertabelo.com/blog/technical-articles/jooq-a-really-nice-alternative-to-hibernate для jOOQ-положительного обзора и http://blog.jooq.org/2012/04/21/jooq-and-hibernate-a-discussion/ для хорошего обсуждения на двух.

Hibernate показался нам привлекательным, потому что он был настолько зрелым и настолько популярен, но когда мы начали сталкиваться с классическими SQL и объектно-ориентированными несоответствиями импеданса, например, как обрабатывать наследование, Hibernate требовал кривой обучения и некоторых накладных расходов на установку.

Мы полагали, что если мы собираемся взять на себя эти накладные расходы, почему бы просто не использовать SQL непосредственно для сопоставления? Итак, мы переключились на JOOQ и смогли написать очень чистый, элегантный и тестируемый код. Если вы не слишком далеко от спящего пути, я бы посоветовал вам взглянуть на jOOQ.

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

Рекомендации по базе данных интеграционного тестирования

Я задавался этот точный вопрос и отправил об этом на https://groups.google.com/forum/#!topic/jooq-user/GkBW5ZGdgwQ. Лукас, автор jOOQ, ответил на некоторые общие замечания.

На этом этапе мы интегрируем тест большинства наших классов DAO и обслуживания. Наши тесты запускаются после flywayClean и flywayMigrate. Затем каждый тест записывается для очистки после себя. Самая большая проблема - производительность, которая пока не является проблемой, но может быть проблемой позже.

Я также разместил на нем и получил полезный ответ. См. https://groups.google.com/d/msg/play-framework/BgOCIgz_9q0/jBy8zxejPEkJ.

Отказ от ответственности: мы близки к запуску нашего приложения, но еще не запускаем его на производстве, поэтому другие могут добавлять дополнительные рекомендации.