WikiDB/Changes

This page contains details of any incompatible changes introduced into WikiDB. I am not documenting compatible changes at the moment, but if there is enough demand for this then I will consider it.

A note on versioning

The version-numbering system I have adopted is based on two numbers:

• The version number is incremented whenever incompatible changes are made. If you are using WikiDB and wish to upgrade to a new version with a higher version number, check out the changes listed on this page beforehand, or things may break! The version number can be seen on Special:Version or at the top of the main WikiDB.php file.
• The revision number is incremented every time I make any changes at all to the code, or to other unrelated code that sits in the same repository. The revision number for each file can be seen at the top of the file, and the revision number for the extension is the highest of these numbers. This is displayed at Special:Version. It is always safe to upgrade to a later revision, as long as the version number has not changed, and you ensure that all files are updated.

In both cases, the only significance of the numbers are that higher numbers are newer. I don't believe in sitting on a 0.x release branch for the rest of my life, so the first version I released is v1, and this will be updated as necessary according to the above rule.

If your version of the code doesn't have a version number, it is v1. If it doesn't have a revision either, it is very old and should definitely be upgraded!

Types of change

There are two types of incompatible changes that may occur:

Changes that require re-parsing all pages in the DB

This type of change occurs when the parser is modified and can only be fixed by either performing a null edit on any affected pages (editing the page, making an edit that won't affect output (e.g. adding a space - though not at the very start or end), and re-saving) or by running a script to re-parse all pages in the DB. I am currently working on such a script, but in the meantime this will need to be done manually.

Changes that require some data-massaging

This type of change occurs when the underlying data-structure changes. These changes don't require any re-parsing of the page, but require modifications to the stored data. This can also be fixed by performing a null edit on any affected pages, but I plan to write a script to handle this.

In both cases the description of the change will indicate the cause of the problem, and if you know that this issue will not have occurred on your wiki then you are safe to skip the update.

Changes between v1 and v2

Changes that require re-parsing all pages

• Table data is now parsed AFTER the parser has stripped nowiki, pre, etc. so on pages where you had either <data> tags or field defintions (i.e. lines in a table namespace starting with >) you may have extra rows in the database that shouldn't be there. For example, if you had a data definition within <nowiki> tags, it would have been counted as table data, whereas now it is correctly skipped. Any pages where this was the case will continue to exhibit the previous incorrect behaviour until re-parsed.

• Table data is now parsed AFTER template expansion, so on pages where you used a template to create a data tag or a field definition the data should now correctly be saved to the DB. If you had pages that used these constructs then the data was not being added correctly in previous versions. Any pages where this was the case will continue to exhibit the previous incorrect behaviour until re-parsed.

Changes that require data-massaging

• Aliases to fields whose name was longer than 255 characters were broken in earlier versions (as the name was truncated for the field, but not for the alias). This is now fixed, however any existing table definitions which include aliases of fields longer than 255 chars will stay broken until they are re-parsed.
• Minor display bug in a few edge cases (with old data from previous versions). If you have a table definition with 'Options' set but no 'Type' then the options are passed to the guessed type. Now they are ignored. In the current codebase this should not be possible, but in previous versions it was possible to set options without a type (e.g. > FieldName:(0,5)). This didn't cause incorrect functioning at all, but could cause incorrect display on the table definition page, and the incorrect data could still be sitting in the DB somewhere.