patchr

If you want to jump right into the action:

• Edit the database section of the configuration file (patchr/patchr_conf.php). Leave the rest of the options to their default values.
• Upload patchr to the public directory of your webserver.
• Use the CLI or the GUI to add and apply patches.

All configuration variables are stored into the

./patchr/patchr_conf.php

Options:

• Database
• Security
• Debug
• Naming
• CLI
• Routes
• Advanced

Basic

Configure all the options and upload to the server. Patchr will create the required table and setup everything automagically.

Advanced

A better way to work with patchr is to version it inside a git repository (such as Bitbucket) and use it as a submodule of your projects.

git submodule add [email protected]:user/your/repo.git ext/patchr/.

You can then initialise the module after cloning with

git submodule update --init --recursive

All frameworks example assume you are using the ext/patchr directory.

• applyDatabasePatches
• reservePatches
• addNewPatch
• getUnappliedPatches
• getLatestAppliedPatch

php patchr.php applyDatabasePatches

php patchr.php reservePatches [int]

php patchr.php addNewPatch [string]

php patchr.php getUnappliedPatches

php patchr.php getLatestAppliedPatch

To access the GUI, hit the patchr.php file in your browser.

Once inside you will be greeted by this clean graphical interface:

To access the GUI within a framework, please refer to the section.

You can play with a GUI demo at demos.0plus1.com

You might want to add patchr to your favorite framework, we've made it easy to achieve this goal.

By default patchr load the configuration options found int the patchr_conf.php file, you can ignore the option in that file by passing a:

$patchr_config_override = array();

You will find an ever updated list of wrappers for common php frameworks on github. Please feel free to contribute!

While Patchr will always try to revert a patch with malformed or unappliable SQL, there is one thing to always keep in mind:

ALTER TABLE `companies_history` ADD COLUMN `action_at` DATE NOT NULL AFTER `action`;
ALTER TABLE `companies_history` CHANGE COLUMN `company_contact_id` `contacted` VARCHAR(255) NOT NULL AFTER `job_id`;

ALTER TABLE `companies_history` ADD COLUMN `action_at` DATE NOT NULL AFTER `action`;

ALTER TABLE `companies_history` CHANGE COLUMN `company_contact_id` `contacted` VARCHAR(255) NOT NULL AFTER `job_id`;

UPDATE `users` SET `complete`=NULL WHERE `id` = 87;
UPDATE `users` SET `complete`=NULL WHERE `id`= 0;

With that in mind, these are our golden rules for patches handling

• One implicit commit statement in each patch
• Always test patches locally before committing
• Only apply database changes through patchr, this will ensure that no issue will raise on deployment
  • With a tool such as MySQL workbench make your changes
  • Copy the preview SQL without applying the change
  • Paste into a new patch
  • Apply patch
• Reserve patches to avoid conflicts in a team environment

By using the config_override array, you can run several parallel instances of patchr from the same codebase.
This is particularly useful to track submodules database changes without polluting the codebase with copies of patchr.
You can achieve this by creating different patchr wrappers files, each with a different table.

// wrapper1.php
$patchr_config_override = array();
$patchr_config_override['db']['table'] = 'patchr_one';
$patchr_config_override['naming']['patches_dir'] = './database-patches-one';
// Your other options
        ...
require_once('./ext/patchr/patchr.php');

// wrapper2.php
$patchr_config_override = array();
$patchr_config_override['db']['table'] = 'patchr_two';
$patchr_config_override['naming']['patches_dir'] = './database-patches-two';
// Your other options
        ...
require_once('./ext/patchr/patchr.php');

As you can see, you will have two independent tables and patches folders, running in parallel from the same codebase