Database Scripts

The Database Scripts project is a series of command line scripts which will dump, erase, restore and merge databases. They are specifically set up to work the best when developing within a version control environment. The primary goals are to:

• keep the database in sync with code
• preserve ability to use the web GUI
• enable a rapid development workflow
• Merge development and production databases

Guess what? There is documentation!

Use Cases

• Reverting your database to the last known good state. Ideal for testing and general development
• Syncing your changes with the changes made by your fellow developers
• Keeping track of changes to the database enabling the ability to remove commits from your history
• Merging the development version with a production version that had content added during development

DBScripts is a series of supporter scripts to help manage the database along side a Drupal installation; it is not an actual module to install within Drupal. Conversion to a module will be part of the process to add it as an extension of drush.

The scripts are run entirely from the command line. The dump, restore and erase scripts can be run with minimal training, but the merge script would most likely require someone more comfortable with the command line and their version control system, and the ability to peruse diffs of the database. The use case for these scripts are non-programmer developers and a deployment manager who performs the merge and deploys the changes to production.

An overview of features:

• Configurable ability to ignore some data for development, while preserving it in production
• Dump and restore to any arbitrary path, allowing you to "cheaply branch" the database when developing
• OPTIONAL ability to change all the AUTO_INCREMENT values (nid, uid, vid, tid, etc), and any tables using it as a foreign key, including related system paths (6.x-2.x) during merge
• Find all tables that are possibly related to a given table (6.x-2.x)
• Minimize conflicts with the users table due to the timestamps constantly changing, by resetting them to the last-merge value (6.x-2.x)

These scripts will become obsolete when an improved system is implemented. There will be no silver bullet, however, many projects are being developed to help: Patterns, CoCKTaiL, Context, Spaces, Deploy. There is also a movement to implement import/export for all configuration options: Exportables, Features. Until all configuration options across all of Drupal and contrib are supported, these scripts will be here for you to help you migrate configuration settings.

If I don't respond to the issue cue in a timely fashion, please feel free to contact me directly via either my Drupal or personal contact form.

Updates

May 30, 2009 - I have continued to test this on a large website, as well as it being used by the rest of the developers within my company. It's working well. Merging for large complicated sites requires some manual tedium which I will try to automate.

April 8, 2009 - I have been heavily testing dbscripts on a semi-large/complicated website in a development and deploy environment where the client is actively adding in content that must be preserved. Its been working beautifully. I have fixed many edge-case bugs and added in a few features. The current HEAD is in the git repository (provided below) because I've been too busy to fiddle with CVS.

February 22, 2009 - The 6.x-2.x version now successfully merges! I don't have a production Drupal 6 site to test this on, though, so I would appreciate any feedback.

January 21, 2009 - The 6.x-1.x version does not support merging. The 2.x version changes the way dumps and restores are treated and has a very basic table-based merge working. Effectively, it takes all content and user data from production and merges it with the other data from development. I am working towards actually merging data now. Documentation will be updated when I get something working.

Alternate Repo

My preferred version control system is git, so everything I do goes there first. I also do not have a wonderful git-to-cvs workflow, so the commits in cvs are not as finely granular as my commits in git, and there is quite a delay between my development and committing to CVS. If you want to a) view full commit log, b) use dbscripts using git instead of cvs, or c) get the latest greatest version, you may access it through github.

• clone url: git://github.com/ceardach/dbscripts.git
• 6.x-2.x page: http://github.com/ceardach/dbscripts/tree/6.x-2.x
• 6.x-2.x commit history: http://github.com/ceardach/dbscripts/commits/6.x-2.x

The only difference between the cvs and git versions is that the config.inc and config.references.inc exist. Master is pointed at the 7.x-2.x branch, so you must switch to the 6.x-2.x branch. There are currently no tags.

Releases

Official releases	Date	Size	Links	Status
5.x-1.1	2009-Feb-22	16.09 KB	Download · Release notes	Recommended for 5.x

Development snapshots	Date	Size	Links	Status
6.x-2.x-dev	2009-May-31	34.6 KB	Download · Release notes	Development snapshot
5.x-1.x-dev	2009-Jan-21	16.09 KB	Download · Release notes	Development snapshot