Database Schema Upgrade
Table of contents
Introduction
Starting from Tiki3, database schema patches are handled differently. Each patch is stored in an individual file, allowing for easier branch merging and more effective schema upgrade.The tiki.sql file still defines the bulk of the database.
Patches and custom coding, in the past, always had to go trough this path, now they do not, which is much better for core development. Also, it allows any custom changes you make to the database to survive through an upgrade.
So, a database upgrade can be made in three different ways:
- From command line, by running installer/shell.php
- From command line, by running doc/devtools/sqlupgrade.php (supports MultiTiki)
- This file doesn't seem to exist - but doc/devtools/sqlupgrade.sh does. I have found it somewhat buggy on MultiTiki sites in that it (or something) seems to loose some of the dirs needed for MultiTiki operation. (jonnyb Sept 2009)
- maybe related to these two bug reports?: (Xavi)
- From the web interface, by running tiki-install.php
For shell scripts, the PHP interpreter must now be available from command line.
Create a new patch
Each file is stored in installer/schema and the naming convention is YYYYMMDD_patch_description_tiki.sql. The SQL file contains a list of semi-colon separated SQL statements. In addition to the SQL file, a PHP file can optionally be defined. The file must have the same name, except with the extension replaced. The file can define a pre_ and post_ function (or both) to be executed before and after the patch. These functions can be used to perform operations to be made during the upgrade that would otherwise be too complicated to do with SQL.
The db/tiki.sql file still has to be updated to reflect the changes for new installations if the patch is to be made on standard Tiki distribution.
Example:
installer/schema/20080922_new_structures_tiki.sql
DROP TABLE tiki_structures; CREATE TABLE tiki_structures ( -- ... ) ENGINE=MyISAM;
installer/schema/20080922_new_structures_tiki.php
function pre_20080922_new_structures_tiki($installer) {
// Store current structures
}
function post_20080922_new_structures_tiki($installer) {
// Restore current structures in new model
}How it works
For updates:
- The script scans for patches available in the folder
- Previously installed patches are pulled from the database
- New patches are ordered for installation
- For each patch,
- Pre function is executed if available
- SQL statements are run
- Post function is executed if available
- Patch installation is saved
- Global scripts are applied
For new installs:
- Runs the usual tiki.sql-derived file to create the base install
- Mark all patches with the _tiki suffix as installed
- Performs update (as above) to apply other patches
Third Party Modifications and Customization
Effectively, any third party modification can add database patches simply by adding the patch file in the patch folder. If the patch does not have the _tiki suffix, it will be applied on new installations. Custom deployments no longer need to maintain the tiki.sql file and will not risk conflicts when updating from the source.
Global scripts
The process also defines global scripts. These scripts are stored in installer/script/ and are PHP scripts. Each file in that folder is executed after the update. The files can be used to perform various operations, like clearing cache or any operation that should be executed after a normal update.
Alias
- DatabaseSchemaUpgrade
- Data Migration Path
- Database Patch
- Database Upgrade
- Code Howtos: Adding fields or tables to the database

Last Comments