v5 Alpha

[jdaigle]

Concepts

• [ ] New convention-based directory structure. The root directory should contain a "migrations" subdirectory which contain the one-time and numbered migration scripts. An optional "objects" subdirectory contain scripts which will run anytime they are modified - it'll also traverse subdirectories to support organization. Any other directory is ignored.
• [ ] Simplified command line. No more "commands". It'll run migrations followed by objects. If any migration has been modified, then hard-stop.
• [ ] By default will prompt before executing scripts; command line switch to run without input (-U)
• [ ] Command line switch to warn on modified migrations and re-execute.
• [ ] Command line switch to execute scripts as a "baseline". I.e. the scripts won't run, but will simply update scripts table.
• [ ] New scripts table to replace "schema_info". Include the text of the script for history.
• [ ] Command line switch to create database for local dev

New Directory Structure Conventions

database_dir/
|-- migrations/
|-- objects/
|    |-- sprocs/ (optional)
|    |-- views/ (optional)
|    |-- functions/ (optional)
|    |-- indexes/ (optional)
|-- misc/ (optional)

Command Syntax

Usage: horton.exe [OPTIONS] COMMAND [PATH]

Path:
  Path to directory containing migrations (leave blank for current directory)

Commands:
 UPDATE     Executes current migrations if no conflicts exist.

Options:
  -f, --files=VALUE path to migrations directory
  -s, --server=VALUE         server hostname.
                               (leave blank for "localhost")
  -d, --database=VALUE       database name.
                               (leave blank to look for "database.name")
  -u, --username=VALUE       username of the database connection.
                               (leave blank for integrated security)
  -p, --password=VALUE       password of the database connection.
                               (required if username is provided)
  -c, --connectionString=VALUE
                             ADO.NET connection string.
                               (optional, overrides other parameters)
  -U, --UNATTEND             Surpress user acknowledgement during
                               execution.
  -v, --version              Print version number and exit.
  -h, --help, -?             show help message and exit.

Examples:
 horton.exe -m "\path\to\migrations" -s LOCALHOST -d Northwind -U
 horton.exe -m "\path\to\migrations" -s LOCALHOST -d Northwind -u sa -p pa55w0rd

[ihilt]

I'm currently managing two databases using essentially the folder structure you are outlining here.

db1\migrations
db2\migrations\

So this makes a lot of sense to me.

The ability to have an objects folder, e.g. views, is a great addition. That way I can track changes to the view and then have horton update the view if it has changed.

How will moving from the schema_info table to the new scripts table work? I currently have TeamCity setup to deploy and horton as a build step so it would break that if horton couldn't take the schema_info history and use it as the scripts history. I'm sure you've thought of that, I was just curious.

Adding a switch for dev sounds good too. I'm interested in how that will work as well.

[jdaigle]

@ihilt thanks for the feedback - I guess I have to be careful now with breaking changes since there are people actually using this tool. :)

A lot of what I wrote about was just some random brainstorming I had last night. I think I've decided that the changes I made in v4 (modular design, new commands, etc) were the wrong choice. Horton should just be a simple migration runner.

To that end, v5 mostly represents a simplification of the tool and the code to that single purpose. And whatever v5 looks like, I'll make sure that one can "upgrade" to it from v4 without significant breaking changes.

[ihilt]

Sounds good. That's how I use it for the most part - as a simple migration runner. Are you going to remove the ADD-MIGRATION command? It's a handy little feature but not critical for me.

On Thu, Aug 3, 2017 at 11:34 AM, Joseph Daigle [email protected] wrote:

@ihilt https://github.com/ihilt thanks for the feedback - I guess I have to be careful now with breaking changes since there are people actually using this tool. :)

A lot of what I wrote about was just some random brainstorming I had last night. I think I've decided that the changes I made in v4 (modular design, new commands, etc) were the wrong choice. Horton should just be a simple migration runner.

To that end, v5 mostly represents a simplification of the tool and the code to that single purpose. And whatever v5 looks like, I'll make sure that one can "upgrade" to it from v4 without significant breaking changes.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jdaigle/Horton/issues/7#issuecomment-320005756, or mute the thread https://github.com/notifications/unsubscribe-auth/AAREVxElz4QCJNBQM99DVABPF6-pMMTZks5sUeiZgaJpZM4Or1OH .