Лучший подход для сборки Java / Maven / JPA / Hibernate с поддержкой нескольких поставщиков баз данных? - PullRequest
3 голосов
/ 14 мая 2010

У меня есть корпоративное приложение, которое использует одну базу данных, но приложение должно поддерживать mysql , oracle и sql * server в качестве параметров установки.

Чтобы попытаться остаться переносимым , мы используем JPA-аннотации с Hibernate в качестве реализации. У нас также есть тестовый экземпляр каждой базы данных, запущенной для разработки.

Приложение прекрасно собирается в Maven , и я поиграл с hibernate3-maven-plugin и может автоматически генерировать DDL для заданного диалекта базы данных.

Каков наилучший способ приблизиться к этому, чтобы отдельные разработчики могли легко протестировать все три базы данных, а наш CI-сервер на базе Hudson мог правильно строить вещи.

Более конкретно:

  1. Я думал, что цель hbm2ddl в просто сгенерирует файл схемы, , но, очевидно, он подключается к действующей базе данных и пытается создать схему . Есть ли способ заставить это просто создать файл схемы для каждого диалекта базы данных без подключения к базе данных?

  2. Если hibernate3-maven-plugin настаивает на фактическом создании схемы базы данных, есть ли способ заставить ее удалить базу данных и воссоздать ее перед созданием схемы?

  3. Я думаю, что у каждого разработчика (и машины сборки Hudson) должна быть своя отдельная база данных на каждом сервере базы данных. Это типично?

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

  5. В hibernate3-maven-plugin есть цель hbm2doc . Кажется излишним запускать это три раза ... Должен поверить, что он будет почти одинаковым для каждой базы данных.

1 Ответ

3 голосов
/ 14 мая 2010

1) Есть ли способ заставить это просто создать файл схемы для каждого диалекта базы данных без подключения к базе данных?

Установите export на false. Примерно так:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>hibernate3-maven-plugin</artifactId>
  <version>2.2</version>
  <configuration>
    <components>
      <component>
        <name>hbm2ddl</name>
        <implementation>annotationconfiguration</implementation>
      </component>
    </components>
    <componentProperties>
      <export>false</export><!-- do not export to the database -->
      <drop>true</drop>
      <configurationfile>src/main/resources/hibernate.cfg.xml</configurationfile>
      <outputfilename>my_schema.ddl</outputfilename>
    </componentProperties>
  </configuration>
</plugin>

2) Если hibernate3-maven-plug настаивает на фактическом создании схемы базы данных, есть ли способ заставить ее удалить базу данных и воссоздать ее перед созданием схемы?

Смотри выше. Но на всякий случай, для этого набора update в true:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>hibernate3-maven-plugin</artifactId>
  <version>2.2</version>
  <configuration>
    <components>
      <component>
        <name>hbm2ddl</name>
        <implementation>annotationconfiguration</implementation>
      </component>
    </components>
    <componentProperties>
      <export>true</export>
      <update>true</update><!-- update the schema -->
      <drop>true</drop>
      <configurationfile>src/main/resources/hibernate.cfg.xml</configurationfile>
      <outputfilename>my_schema.ddl</outputfilename>
    </componentProperties>
  </configuration>
  <dependencies>
    <dependency>
      <groupId>org.apache.derby</groupId>
      <artifactId>derbyclient</artifactId>
      <version>10.5.3.0_1</version>
    </dependency>
  </dependencies>
</plugin>

3) Я думаю, что у каждого разработчика (и машины сборки hudson) должна быть своя отдельная база данных на каждом сервере базы данных. Это типично?

Да, и я считаю это наилучшей практикой (см. Использование одного экземпляра базы данных на разработчика ).

4) Разработчикам придется запускать Maven три раза ... по одному для каждого поставщика базы данных? Если да, как объединить результаты на компьютере сборки?

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

5) В hibernate3-maven-plugin есть цель hbm2doc. Кажется излишним запускать это три раза ... Должен поверить, что он будет почти одинаковым для каждой базы данных.

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

...