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

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

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

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

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

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

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

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

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

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

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


build hibernate jpa maven-2 hbm2ddl hibernate3-maven-plugin
person HDave    schedule 14.05.2010    source источник

Ответы (1)


arrow_upward
3
arrow_downward

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. Кажется излишним запускать это три раза ... Я думаю, это будет почти идентично для каждой базы данных.

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

person Pascal Thivent    schedule 14.05.2010
comment
Большое спасибо. Настройка export = false сделала свое дело. Немного расстраивает то, что документация hibernate3-maven-plugin настолько бедна. Также спасибо за подсказку о матрице построения Гудзона, она выглядит именно так, как прописал врач. - person HDave; 14.05.2010
comment
@HDave Да, документация не является его самой сильной стороной (и, к сожалению, есть небольшие несоответствия с соответствующими задачами ant). - person Pascal Thivent; 14.05.2010