User Guide

G Suite




Create spatial database:

Install FastVersion infrastructure in a Database:

  1. The system will automatically create tables and a set of functions, views, rules and restrictions in the database. Most of the functionality is actually stored in the database not in the python plugin.

FastVersion toolbar


Convert to versioned table:

Schema "versioned" is where the functions, procedures, tables, and queries are created.

Every table to be versioned must be placed in the "versioned" schema.

When a table is versioned, a set of fields are added to it.

Note:If a table is imported with existent data, the id field must be unique,bigint , primary key, and not null.

Note: After it is versioned, the id field is managed automatically by the system.

Versions, Users, Projects.

Add a user, set permissions, create version, and feature edition:




Advanced users:

If the schema of the base table is modified(added fields, deleted fields, types, field names, etc.), the old layer must be deleted and the version re-opened(wich will regenerate the views, the layers and the group).

Schema evolution:

Schema evolution, refers to the problem of evolving a database schema:

Some database administrator will need to:

Add Table: Convert to a versioned one.

Delete Table: Is simple, just delete the base table from database.

Other tasks involving: renaming tables, adding fields, deleting fields, renaming fields, changing(convert) field types, will need some skills from the database manager.

FastVersion, stores all the information in the base table and the "version"table. So, if you delete all the views, and the functions, they will be recreated correctly after the change.

Generation of the version code “trunk version-alternative-subalternative”:

The system will generate a view for each version, every time the version is opened, the view is recreated


The base version is 0.0.0, in the trunk version the next will be 1.0.0, 2.0.0 and so on.


The alternative field has a minimum value of 1, ie the first alternative of version 0.0.0 will be 0.1.1 Versions 0.0.1 or 1.0.1, etc. are impossible. The 1st alternative is 1. The subalternative number for an alternative is always 1.


The subalternative field has a minimum value of 2, ie the first subalternative of alternative 0.1.1 will be 0.1.2 The first sub-alternative is 2. That is, versions 0.1.1, 1.1.1, 2.1.1, 3.1.1. are alternatives and not subalternatives. Versions 0.0.1 or 0.1.0 or 1.0.1, etc. are impossible.

General rule:

For all notation v(trunk), a(alternative), s(sub alternative):

If a = 0 is a trunk version. ( ?_0_? )

If s = 1 is an alternative Version.( ?_?_1 )

If s> 1 is a subalternative Version.( ?_?_2 )... ( ?_?_3 )... ( ?_?_73 )

The views and therefore the name of the layer created for the version display has the following structure [version name] _ [trunk version] _ [alternative] _ [subalternative]


The plugin was developed to work with a postgis server(Postgres 9.6).

The system creates one table (the Version table), but also creates a set of functions, views and rules in an schema named ”versioned” to make everything work, they should only be manipulated by the versioning system. When the versioning system is created, version 0.0.0 is automatically created.