[MyBatis Schema Migration System 3.0.2] - New features proposal and patch file

[GoogleCodeExporter]

Hi,

I'd like to submit you a set of new features for the next release of MyBatis 
Schema Migrations System. A SVN patch file is attached to this issue : 

Feature 1 : Organize migrations scripts into a folder hierarchy.
--------------------------------------------------------------

It's often useful to organize migration scripts into a folder hierarchy.

For example :
-------------

When the 'new' command is used the migration script is created in the "script" 
folder but may be move in any folders under "scripts" to group migrations 
scripts by version.

> migrate new "insert customer 1"
Creating: 20101011134102_insert_customer_1.sql
Done!

Assume we organize our folder hierarchy like that : 

\_scripts
   \_ 1.x
      \_ 1.0.1
           20101011134102_insert_customer_1.sql
      \_ 1.0.2
           20101011136753_insert_customer_2.sql
  bootstrap.sql

All migrations scripts under the scripts folder are viewed (recursive):

> migrate status

ID          Tag     Applied At          Description
================================================================================
==========
20101011130822                  2010-10-14 16:05:28     create changelog
20101011134102                ...pending...         insert consumer 1
20101011136753                ...pending...         insert consumer 2

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
------

Feature 2 : Tag a set of migrations scripts with a human readable tag (ie : 
1.0.1).
--------------------------------------------------------------------------------

---

It may be useful to tag a script or a set of scripts with a tag in order to 
rollback more easily to a previous tag.

For example :
-------------

> migrate status

ID          Tag     Applied At          Description
================================================================================
==========
20101011130822                  2010-10-14 16:05:28     create changelog
20101011134102                ...pending...         insert consumer 1
20101011136753                ...pending...         insert consumer 2

Now we run the unapplied migration script and set a tag to this script (1.0.1)

> migrate up 1 --tag=1.0.1

The first pending script was run and the tag 1.0.1 will be associated in 
database to this script.

> migrate status

ID          Tag     Applied At          Description
================================================================================
==========
20101011130822                  2010-10-14 16:05:28     create changelog
20101011134102      1.0.1       2010-10-14 16:31:21     insert consumer 1
20101011136753                ...pending...         insert consumer 2

NOTE : The tag attribute may be used only with up and pending command.

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
------

Feature 3 : Use a Tag command instead the Version command.
----------------------------------------------------------

A tag command may be use instead of Version command to migrates the database to 
a specified tag.
Actually the tag command look for the last version with the tag specified and 
up or down the changes (call the version command).

For example :
-------------

> migrate status

ID          Tag     Applied At          Description
================================================================================
==========
20101011130822                  2010-10-14 16:05:28     create changelog
20101011134102      1.0.1       2010-10-14 16:31:21     insert consumer 1
20101011136753      1.0.2       2010-10-14 16:31:21     insert consumer 2

> migrate tag 1.0.1

> migrate status

ID          Tag     Applied At          Description
================================================================================
==========
20101011130822                  2010-10-14 16:05:28     create changelog
20101011134102      1.0.1       2010-10-14 16:31:21     insert consumer 1
20101011136753                ...pending...         insert consumer 2

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
------

Feature 4 : Add context section in a migration script to control which will be 
executed in any particular migration run.
--------------------------------------------------------------------------------
----------------------------------------

The contexts concept is similar to Liquibase  : 
http://www.liquibase.org/manual/contexts

For example :
-------------

Declare a context to execute in "development.properties" configuration file :

==========
... 

# A comma separated list of contexts to execute.
# If not specified, all contexts are run.
contexts=dev

...
==========

Declare a context section in a migration script :

--//@CONTEXT=staging
INSERT INTO `consumer` (`id`,`key`,`secret`,`label`) values (7, 
'rqsdqsdDub7ZtA', 'pLqsqs', 'If contexts are set in environment properties 
files, this data will be inserted only for 'staging' context');
--//~@CONTEXT

The contexts set in the configuration file and in the migration scripts doesn't 
match, so the section of the script will be not run.

That's all. Sorry for my poor english !!!

Nicolas Huray

Original issue reported on code.google.com by nicolas....@gmail.com on 14 Oct 2010 at 4:10

Attachments:

• mail.txt
• additional-features.diff

[GoogleCodeExporter]

Features 1 and 2 may be interesting, because are optional and, well used, could 
be necessary to manage large and old systems which have hundred of scripts. An 
example could be if I were working in a DB release and I want to assume old 
releases development are closed.

Feature 3 brake simplicity and lose the unique development flow because could 
be bad used. I think this feature is dangerous and not so useful, because if 
you need special data you should "inject" this externaly but no in the "schema 
system". 

Original comment by acorralo...@gmail.com on 6 Apr 2011 at 10:21

[GoogleCodeExporter]

Original comment by nathan.m...@gmail.com on 12 Sep 2011 at 4:03

• Added labels: Type-Feature
• Removed labels: Type-Defect

[GoogleCodeExporter]

I came here today for the purpose of seeing if requested Feature 1 had been 
previously requested. I work on a project where we produce about 30 - 50 
migrations a release. We have an old database which needs lots of changes and 
at the same time we need to modify it to support new features which are 
constantly being added. We also don't have organizational buy in for the 
migration product and being able to move all scripts into a release folder at 
the end of a release will make it much easier for us to keep track of which 
migrations are needed in production for our current release.

If this features priority can't be elevated by a single comment on this ticket 
then I would offer my free time to work on it myself if granted such 
permission. It is something that is really needed and I would hate to have a 
custom version of MyBatis which would prevent an upgrade path later. 

Original comment by gllo...@gmail.com on 16 Nov 2011 at 3:39

[GoogleCodeExporter]

I have the same opinion with Mr Nicolas Huray for Features 1 and 2 because 
these are very useful, because these features allow developers to work with one 
BD (if for example we use Oracle) we can’t create instance of oracle BD for 
each developers.

Original comment by mabdelouhab@gmail.com on 29 Dec 2011 at 11:44

[GoogleCodeExporter]

One other is to not work with directories name “scripts” hardly coded, 
allow modify the name by adding a variable name in “development.properties” 
file
\ _drivers
\_ environments
  \ development.properties
\_scripts
   \_ 1.x
      \_ 1.0.1
           20101011134102_insert_customer_1.sql
      \_ 1.0.2
           20101011136753_insert_customer_2.sql
  bootstrap.sql

Original comment by mabdelouhab@gmail.com on 29 Dec 2011 at 11:51

[GoogleCodeExporter]

Original comment by eduardo.macarron on 29 Jan 2012 at 12:56

• Added labels: Component-Migrations

[GoogleCodeExporter]

Since commenting on this I have come to the conclusion that the real problem 
here is that a good solution to creating a baseline of a schema is not present. 
If there were a good solution to creating a new bootstrap after a release that 
included updates to the "schema_version" table then this would be a moot issue 
all together. I don't support the idea of subdirs within the scripts directory 
any longer. I think this will add bloat to the configuration and will encourage 
rot, especially the suggestion by mabdelouhab. I do think that it would be nice 
to be able to configure the scripts directory in general. In my current 
environment the entire migration would be exported from svn anyway so it would 
be ideal to just have the executables in one location and then update the 
properties to point to the current location of the exported scripts. 

Original comment by gllo...@gmail.com on 29 Jan 2012 at 1:41

[GoogleCodeExporter]

Original comment by chengt on 15 Aug 2012 at 7:51

[GoogleCodeExporter]

glloyd1 please look at the latest code in migration trunk. I added support for 
specifying script directories.
I need to look more at this ticket but that should at least solve the case of 
custom sets of scripts?

Original comment by chengt on 16 Aug 2012 at 3:33