По сути, у меня всё точно так же. Тег jdbc:embedded-database по умолчанию поднимает HSQLDB. Юнит для краткости кода настраивается прямо в entityManagerFactory, и его точно так же можно инъектировать с помощью @PersistenceUnit. Единственное отличие — в моём случае схема пересоздаётся автоматически за счёт присутствия аннотации @DirtiesContext.
Хорошо. В таком случае, возвращаясь к вопросу, «почему бы там была привязка» — отвечаю, что привязка теста к конкретной БД будет заключаться именно в «конкретном диалекте конкретной DBMS», который заключается отнюдь не только в способе разделения инструкций.
Разные БД — разные диалекты, разные типы данных в маппингах. Из моего опыта, даже на простейших типах данных (boolean, например) уже начинаются проблемы несовместимости скриптов. Что уж говорить о каких-нибудь LOB'ах.
Да, насколько я знаю, такой возможности нет.
Но XML-формат предоставляет всё-таки небольшую абстракцию над базой данных. В этом и преимущество DBUnit. Интеграционные тесты и так достаточно чувствительны, стоит ли привязывать их к SQL-синтаксису конкретной БД.
Не понимаю, 1) почему они назвали эту статическую табличку app (приложение), и 2) почему эта статическая табличка нормально открывается только в Chrome.
Но нельзя задать используемую версию на уровне приложения. Чтобы оно говорило: «Мне нужна Java 5, а то, что у тебя тут стоит Java 7, меня не волнует». Обратная совместимость Java, увы, небезупречна.
Новые конструкции не добавляются ввиду тормознутого JCP и общего курса партии на максимальную обратную совместимость. Майкрософту легче, они сами себе хозяева, да и проблему с обратной совместимостью решили немного по-другому — установкой множества версий .NET, которые могут работать параллельно и не мешать друг другу. Поэтому платформа .NET более динамична, чем Java.
Бросьте, синтаксис — это ещё не весь язык. Java окружена огромнейшей экосистемой, которая не даст ей погибнуть ещё очень долго, и вообще предпосылок для её гибели не наблюдается. Если разработчики и начнут перебегать в стан Microsoft, то уж точно не из-за того, что в C# раньше, чем в Java, появляются какие-нибудь там замыкания или континуации.
К сожалению, нестатическими блоками инициализации нельзя инициализировать объекты, подлежащие сохранению в БД, так как JPA-провайдер «не узнаёт» анонимный класс.
Зато эту особенность языка Java удобно использовать при написании DSL или fluent API.
Да, и мне ещё вот что кажется забавным — во многих JS-библиотеках была тенденция отхода от разметки в HTML в пользу генерации всей страницы в JavaScript, что в некоторых отношениях было удобно, но создавало мешанину из логики и разметки. Теперь вот — возврат к декларативной разметке, а в коде, как и полагается, остаётся логика.
my.opera.com/chooseopera/blog/2012/04/01/please-help-us-with-our-data-problem
Я вообще-то и говорил про привязку конкретных тестов.
Предлагаю закончить этот демагогический тред.
Обнаружены взаимоисключающие параграфы. Так всё-таки, стандартный SQL, или конкретный диалект конкретной DBMS?
Но XML-формат предоставляет всё-таки небольшую абстракцию над базой данных. В этом и преимущество DBUnit. Интеграционные тесты и так достаточно чувствительны, стоит ли привязывать их к SQL-синтаксису конкретной БД.
Зато эту особенность языка Java удобно использовать при написании DSL или fluent API.
Перенёс.