Nooku Project Nooku Components

1. Description

The objective of com_versions is to make it painless for any developer to implement version control in any Nooku powered component.

2. Functionality

2.1 Save overwritten data

The original data of a content item should be saved to a separate versions table after a successful edit/overwrite. Detailed draft

2.2 Fetch version X

If given a revision parameter, for instance option=com_harbour&view=boat&id=15&revision=3, the database behaviour should seamlessly load revision 3 of boat 15. Perhaps both the most recent version should be loaded too. Authenticated user required of course.

2.3 Tras behaviour

When an item is deleted, a database behaviour should insert the deleted data into the versioning table. From here we need functionality for both emptying the trashcan (delete item and all item versions), and restoring items.

2.4 Compare versions X and Y

The ability to compare two versions of an item. This is perhaps most of all a GUI challenge, especially if you want to view both versions side-by-side. One alternative—and perhaps the easiest way—is to do things the Google Docs style; just let you easily switch between versions.

3. Design consideration

3.1 Versions table or tables?

Should the versions table be a duplicate of the original table, or should all version history be stored in one versions table, JSON style? I am leaning towards the latter, to avoid database table-mania, where every database table is duplicated. One table also makes it easier to perform operations on the entire database, like for instance deleting obsolete versions and emptying trash.

3.2 Version data

Should we store complete copies of items, or just the changed parts? If storing only changed parts, we will require a compilation operation to view revision X, as it will have to be reverse-engineered from the current version and through all newer versions. Storing complete items does however require a much larger storage capacity.

Should we store all of the changed data or be able to exclude some parts from versioning altogether? Some table columns need not change at all, some

3.3 Garbage collection

Should we perhaps also implement some sort of garbage collection or content rot routine, to systematically clean out very old item revisions to reduce the data storage usage? Maybe a revision TTL or maximum number of revisions per item?

3.4 Behaviour compatibility

Must be compatible with the other database behaviours. Have to figure out how to address data changes done by other database behaviours, to make sure they are done in the proper order.

3.5 Include lockable behaviour

As per the ideas of eZ publish and it's handling of editing conflicts. One behaviour to rule them all?

3.6 Workflow implications

Unpublished new versions of content should not replace published older versions, when in an edit-review-publish type of workflow where a new object isn't necessarily published automatically.