Устойчивый мир с изменениями базы данных в среде Java

Устойчивый мир для нас — это устранение неопределенности. В этом случае изменения базы данных приветствовали идею Active Record Migrations of Ruby.

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

Цель

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

Для этого нам нужно найти простой инструмент с базовой группой характеристик, как следующие:

• Работает с любой базой данных, хотя сейчас наша база данных MySQL.
• Разрешить одновременным разработчикам работать независимо.
• Включить различные среды разработки.
• Возможность интеграции с любой системой контроля версий.
• Возможность легко интегрировать задачи миграции в Apache Ant.
• Разрешить прямую и обратную миграцию и конфликты, легко управляемые.

Мы выбираем инструмент MyBatis Migrations в качестве лучшего решения для нас и сценарий Ant GitHub для запуска команд MyBatis Migrations в качестве начальной строки.

Давайте перейдем к вопросу: как мы работаем с миграциями

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

Первый раз

• Создайте каталог миграции в каталог нашего проекта.
• Загрузите файл миграции MyBatis Schema mybatis-migrations-3.1.1-bundle.zip .
• Создайте каталог lib и скопируйте mybatis-3.2.3.jar и mybatis-migrations-3.1.1.jar .
• Загрузите Ant-задачи build.properties и build.xml файлы из mybatis-migrations-anttasks-master.zip и переименуйте их в migrations.properties/xml для более ясных целей.
• Очевидно, что эти файлы определяют задачи муравья и основные свойства для инструмента миграции, в то время как migrations.properties (комментарии включены для четко) определяет

  01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

  # Default environment mybatis.default.environment=development   mybatis.dir=migrations mybatis.lib.dir=${mybatis.dir}/lib   mybatis.repository.dir=${mybatis.dir}/db   # This directory contains your migration SQL files. These are the files # that contain your DDL to both upgrade and downgrade your database # structure. By default, the directory will contain the script to # create the changelog table, plus one empty example migration script. mybatis.scripts.dir=${mybatis.repository.dir}/scripts   # Place your JDBC driver .jar or .zip files in this directory. # Upon running a migration, the drivers will be dynamically loaded. mybatis.drivers.dir=${mybatis.repository.dir}/drivers   # In the environments folder you will find .properties files that # represent your database instances. By default a development.properties # file is created for you to configure your development time database # properties. # You can also create test.properties and production.properties # files. The properties file is self documented. mybatis.env.dir=${mybatis.repository.dir}/environments

  и migrations.xml определяет задачи муравья, как вы можете видеть в исходной документации . Конечно, вы должны переименовать его как свойство дескриптора файла XML, чтобы загрузить его

  1 2 3 4 5 6 7 8

  <?xml version="1.0" encoding="UTF-8"?> <project name="MyBatis Migrations" basedir="."          default="db:migrate:status">       <property file="migrations/migrations.properties" />   ..... </project>

• Но как его установить … Это легко, в основном мы должны выполнить:

  1	$ ant -f migrations.xml db:migrate:init

  Он создает каталоги и исходные файлы, как они были определены в migrations.properties, как вы можете видеть в этом выходном журнале

  01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

  Buildfile: /wpr/myproject/migrations/migrations.xml    db:migrate:init:      [echo] ** Executing "migrate init" on "development" environment **       ------------------------------------------------------------       -- MyBatis Migrations - init       ------------------------------------------------------------       Initializing: db       Creating: environments       Creating: scripts       Creating: drivers       Creating: README       Creating: development.properties       Creating: bootstrap.sql       Creating: 20131123174059_create_changelog.sql       Creating: 20131123174100_first_migration.sql       Done!              ------------------------------------------------------------       -- MyBatis Migrations SUCCESS       -- Total time: 2s       -- Finished at: Sat Nov 23 18:41:00 CET 2013       -- Final Memory: 1M/117M       ------------------------------------------------------------.    BUILD SUCCESSFUL Total time: 3 seconds

  пока

  • окружения , скрипты и драйверы являются каталогами (как видно ранее).
  • README , который объясняет содержимое каталогов, как следует из названия.
  • bootstral.sql , в который необходимо включить актуальную схему базы данных. Вам нужно начать с известного состояния.
  • 20131123174059_create_changelog.sql содержит контрольную таблицу по умолчанию для инструмента миграции. Это цена, которую вы должны заплатить.
  • 20131123174100_first_migration.sql будет вашим первым файлом миграции SQL. Вы можете удалить или переименовать его, хотя вы должны сохранить формат как ггггммдд ЧЧММсс_ .
• Сохранение свойств базы данных migrations / db / environment / development.properties для среды разработки

  1 2 3 4 5

  ## JDBC connection properties. driver=com.mysql.jdbc.Driver url=jdbc:mysql://localhost:3306/<databaseName> username=root password=root

• При необходимости добавьте другие файлы свойств среды в каждую миграцию / db / environment / <environment> .properties .
• В качестве последнего шага поместите вашу фактическую схему базы данных в файл bootstrap.sql .

День за днем

Среди всех команд переноса мы обычно используем

• Создайте одну или несколько миграций, выполнив db: migrate: new .
• Примените миграцию к базе данных, выполнив команду db: migrate: up .

Дополнительные шаги включены:

• Вернуть миграцию, если это необходимо для разрешения конфликтов. Любая ошибка может быть легко решена с помощью db: migrate: down … но помните, что это делается за один шаг .
• Примените отложенные миграции не по порядку, если это безопасно с помощью db: migrate: pending или db: migrate: version . На самом деле, если вы хотите выполнить эти задачи, вам придется добавить код, принадлежащий migrations.xml

  01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20

  <?xml version="1.0" encoding="UTF-8"?> <project name="MyBatis Migrations" basedir="." default="db:migrate:status"> ....       <!-- $ migrate pending -->     <target name="db:migrate:pending" description="Runs all pending migrations regardless of their order or position in the status log">         <migrate command="pending" environment="${environment}" />     </target>       <!-- $ migrate version -->     <target name="db:migrate:version" description="Migrate the schema to any specific version">         <input addproperty="specific.version" message="Specific version to migrate:" />         <migrate command="version" environment="${environment}">             <extraarguments>                 <arg value="${specific.version}" />             </extraarguments>         </migrate>     </target>   </project>

• Создайте сценарии миграции для запуска в автономном режиме в средах, которые находятся вне вашего контроля.
• Получите статус системы в любое время, выполнив команду db: migrate: status .

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