Introduction
The use-cases and requirements for this design are outlined in Records and RecordStores. This document will describe the proposed model object, REST APIs, and usage patterns of a new Synapse object called a TableEntity.
A TableEntity is a new Entity type that has many of the attributes of a relational database table. In fact, we will adopt all of the nomenclature from: http://en.wikipedia.org/wiki/Relational_database.
Object Model
The following class diagram shows how TableEntity integrates with the rest of the Entity model objects:
The TableEntity is a model object that describes the table including the columns and any constraints. The TableEntity model object does not encapsulate any row data. Instead, separate services will be provided to add, update, delete, fetch and query rows from a table entity. A TableEntity can have an ACL like all other Synapse Entities that can be used to restrict access to the table and all of its rows. We are not planning to support row level authorization at this time.
REST API
| URL | Method | Request Body | Response Body | Description | Authority |
|---|---|---|---|---|---|
| /entity | POST | TableEntity | TableEntity | Create a new TableEntity as you would any other Entity in Synapse. A new TableEntity will not have any rows. Add rows see POST /table/<id> | Must have the CREATE permission on the parent entity of the table. |
| /entity/<id> | GET | TableEntity | Get a TableEntity as you would any other Entity in Synapse | Must have READ permission on the Entity | |
| /entity/<id> | PUT | TableEntity | TableEntity | Update the TableEntity. | Must have UPDATE permission on the Entity |
| /entity<id> | DELETE | Delete a TableEntity and all of its rows. | Must have DELETE permission on the Entity | ||
| /entity/<id>/table | POST | ResultSet | TableRowReference | This method is used to both add and update rows to a TableEntity. The <id> must be the ID of the TableEntity. The passed ResultSet will contain all data for the rows to add or update. The ResultSet.rows is a list of Rows, one of each row to add or update. If the Row.rowId is null, then a row will be added for that request, if a rowId is provided then the row with that ID will be updated (a 400 will be returned if a row ID is provided that does not actually exist). The Row.values list should contain a value for each column of the row. The ResultSet.headers identifies the columns (by name) that are to be updated by this request. Each Row.value list must be the same size as the ResultSet.headers, as each value is mapped to a column by the index of these two arrays. When a row is added it will be issued both a rowId and a version number. When a row is updated it will be issued a new version number (each row version is immutable). The resulting TableRowReference will enumerate all rowIds and versionNumbers for this update. The resulting RowReferecnes will be listed in the same order as the passed result set. A single POST to this services will be treated as a single transaction, meaning all of the rows will be added/updated or none of the rows will be added/updated. If this web-services fails for any reason all changes will be "rolled back". | Must have UPDATE permission on the TableEntity identified by the <id> |
| /entity/<id>/table | DELETE | RowDeleteRequest | Delete all rows identified in the request. When a row is delted it will now longer appear in queries. However, old version of the row will still exist and may still be referenced and retrieved from the POST /entity/<id>/table/version call. | Must have DELETE permission on the Entity | |
| /entity/<id>/table?query="<sql like queryr>" | GET | ResultSet | Query the rows of a table with a "SQL like" query string. For example: "select * from <table_id> where foo=bar limit 100 offset 0" | Must have READ permission on the table. | |
| /entity/<id>/table/version | POST | TableRowReference | ResultSet | Given a TableRowReference, get the ResultSet of the rows. Each RowReference of the requested can included a versionNumber. When a versionNumber is included the data for that row will be from the requested version number. If the versionNumber is blank or null then the current version of that row will be returned. | Must have READ permission on the table. |
Row Versions
A Table Entity does not have multiple versions. Instead, each row is issued a version number when created. A version of a row is immutable. When an row is updated, a new version of that row is added and issued a new version number. Each version of a row can be referenced using a RowReference object that includes both the rowId and a versionNumber. While is is possible to fetch an old version of a row (see POST /entity/<id>/table/version), it is not possible to query for old row version.
Table Query
Synapse will automatically create an index of the current rows of each table entity. This index will be used to support all SQL-like queries against a table. Since the index only contains the most recent (or current) version of each row, it is only possible to query against the current version.
Table metadata Updates
Columns and constrains can be added or removed from a TableEntity at any time. This is done by updating the TableEntity (similar to all Entity updates). However, a few items should be considered:
- A constraint can only be added if the all existing data already meets the constraint or a 400 will be returned.
- When a column is added a default value should be provided in the column model, if not the default value will be null.
- When a column is removed, old version of each row will retain the values of the deleted column.