Version Control in GraphSpace GSOC '18

Changes in GraphSpace Model

Following changes have been made to GraphSpace's model the implementation of versioning feature -

• Added Table graph_version
• Moved graph_json and style_json from graph table to graph_version table.
• Added column default_version_id in graph_version . default_version_id stores the id of default version of the Graph.
• Two SQLAlchemy relationships have been defined between graph & graph_version table.

Major changes have been made in the Graph table to implement Graph Version feature. The graph_json & style_json have been migrated to GraphVersion table. A column default_version_id has been added to Graph table, it stores the id of the default version of the graph. The Graph APIs have not been affected in a major way (default_version_id parameter has been added to link a graph to a particular version), however, the API is still backwards compatible with the previous format/parameters.

Code for read, create, update and deletion of Graphs have been modified to incorporate the above changes in GraphSpace.

Operations on graph

To load a Graph in GraphSpace, first graph table is queried to get META_DATA like name, owner_email, description and default_version_id. Then, the default_version_id is used to fetch data from the graph_version table. Graph_version table returns graph_json and style_json data which is then combined with data from the graph table. It is then sent to the client in a HTTP response.

When creating a new graph, first an entry is added to the graph table. Next, graph_json & style_json data needs to be stored in the graph_version table. To do this a new entry is added to the graph_version table -where the graph_id field of graph_version is set to the id we got from the graph table.

Update and delete operations are handled in a similar way using the SQLalchemy relationships between graph and graph_version tables.

---

Old graph model vs current graph model

Versioning Feature details

Create Graph Version : A graph version is created by default when a new graph is created. Users can also create graph version for existing graphs. Currently, graph versions can only be added using the REST APIs.
Example,
POST : http://127.0.0.1:8000/api/v1/graphs/<graph_id>/version/
This will create a new graph version for the graph with ID - graph_id.

GET/read graph version : When a Graph is opened, all the versions associated with that graph are fetched from the graph_version table. Specific graph versions can also be fetched using graph_version_id
Example,
GET : http://127.0.0.1:8000/api/v1/graphs/<graph_id>/version?owner_email=<user_id>
Query all the versions of graph with id - graph_id.
GET : http://127.0.0.1:8000/api/v1/graphs/<graph_id>/version/<graph_version_id>?owner_email=<user_id>
Query graph version with ID - graph_version_id and graph ID - graph_id

Delete graph version: Non-default graph versions can be deleted using GraphVersion REST API, however, to delete a default graph version a different version needs to be made default before deleting it.
Example,
DELETE : http://127.0.0.1:8000/api/v1/graphs/<graph_id>/version/<graph_version_id>?owner_email=<user_id>
This will delete graph version with ID graph_version_id for graph with id graph_id

More information about REST API usage has been documented in API specifications
View API RAML as HTML document

Tests

Tests for the Graph versioning feature have been added in graphs\tests.py. It covers tests for create, read, update, delete and foreign key & other constraints.