java实现数据库内容修改_数据库更改到Java环境中实现可持续和平-CSDN博客

java实现数据库内容修改

对我们而言，可持续和平正在消除不确定性。在这种情况下，由于数据库更改，欢迎使用Ruby的Active Record Migrations 。

迁移对我们意味着什么？嗯，这是一种方便快捷的方法，可以以一致且简便的方式来改变我们的数据库架构，从而消除了软件开发过程中有关数据库更改的许多不确定性。

目标

我们的目标是根据项目的发展和演变，保持对数据库的生命周期，并对更改进行绝对控制。

为此，我们必须寻找一个具有以下基本特征的简单工具：

尽管现在我们的数据库是MySQL，但可以与任何数据库一起使用。
使并发开发人员能够独立工作。
启用不同的开发环境。
能够与任何版本控制系统集成。
能够轻松地将迁移任务集成到Apache Ant中。
允许向前和向后迁移以及容易管理的冲突。

我们选择MyBatis Migrations工具作为最适合我们的解决方案，并选择GitHub存储库Ant脚本来运行MyBatis Migrations的命令作为起点。

让我们说出重点：我们如何处理迁移

通过这些工具，我们认为迁移的生命周期可能像这样

第一次

在我们的项目目录中创建一个迁移目录。
下载MyBatis Schema迁移文件mybatis-migrations-3.1.1-bundle.zip 。
创建一个lib目录并复制mybatis-3.2.3.jar和mybatis-3.2.3.jar mybatis-migrations-3.1.1.jar文件。
从mybatis-migrations-anttasks-master.zip下载Ant任务的build.properties和build.xml文件，并将其重命名为migrations.properties/xml以获得更清晰的目标。

显然，此文件定义了迁移工具的ant任务和基本属性，而migrations.properties （包含注释以清楚地说明）定义了

# 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定义了ant任务，您可以在原始文档中看到。当然，您必须将其重命名为xml文件描述符属性才能加载它

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

	<property file="migrations/migrations.properties" />

.....
</project>

但是，如何安装 ……很容易，基本上我们必须执行以下操作：

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

如在此输出日志中所见，它将创建目录和初始文件（如在migrations.properties中定义的一样）。

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

而

环境，脚本和驱动程序是目录（如前所述）。

保留开发环境的migrations / db / environment / development.properties数据库属性

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

如果需要，将其他环境属性文件添加到每个migrations / db / environment / <environment> .properties 。
最后一步，将您的实际数据库架构放入bootstrap.sql文件中。

日复一日

在我们通常使用的所有迁移命令中

使用db：migrate：new创建一个或多个迁移。
通过db：migrate：up将迁移应用于数据库。

可选步骤包括：

如有必要，请还原迁移以解决冲突。使用db：migrate：down ..可以轻松解决任何错误，但请记住，仅一步之遥 。

如果可以安全地使用db：migrate：pending或db：migrate：version来应用挂起的迁移，请按顺序进行。实际上，如果您想执行这些任务，则必须将代码添加到migrations.xml中

<?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>