Fullscreen
[Show/Hide Right Column]

Database Schema Upgrade



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. This file is taken by a shell script and modified to work with various different data bases: sqlite, PostgreSQL so after modifying tiki.sql, make sure you run convertsqls.sh (while you are in its directory, db/convertscripts), and commit back all the affected files. Starting in Tiki5, no need to use convertscripts as Database independence has been dropped.

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:

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. Additionally, convertscripts must be ran to reflect changes in tiki.sql in the installer.

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:
  1. The script scans for patches available in the folder
  2. Previously installed patches are pulled from the database
  3. New patches are ordered for installation
  4. For each patch,
    1. Pre function is executed if available
    2. SQL statements are run
    3. Post function is executed if available
    4. Patch installation is saved
  5. Global scripts are applied

For new installs:
  1. Runs the usual tiki.sql-derived file to create the base install
  2. Mark all patches with the _tiki suffix as installed
  3. 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


Page last modified on Thursday 28 October, 2010 12:08:26 UTC

Search Wishes (subject only) [toggle]

Keywords

The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.