Page Comparison

...

X-MMS-Context-Project-Id: Project.Example
X-MMS-Context-Ref-Id: 
X-MMS-Context-Commit-Id: Commit.8f1dd
X-MMS-Conflict-Commit-Id: Commit.17ccd

Update algorithm

1.0. Input values

Let the following identifiers represent constant values given by the update request:

• PROJECT_ID and REF_ID- taken from path parameters /projects/{PROJECT_ID}/refs/{REF_ID}

• UPDATE_CONDITION - the WHERE block of the SPARQL update body

• TERMINAL_COMMIT_ID - taken from the requisite X-MMS-Context-Commit-Id header

1.1. Commit selection

The first set of IO operations that take place on the server are about finding a version of the model that satisfies the UPDATE_CONDITION. If there is no UPDATE_CONDITION in the update request, the algorithm selects the latest commit associated with the given REF_ID (by targeting it in the upcoming metadata update operation) and proceeds to 1.2. .

Unfortunately, the SPARQL 1.1 Protocol does not standardize any type of response content to a SPARQL Update request. Some triplestores will provide detailed information about how many triples were affected by an update, while others simply indicate whether the request succeeded or failed as an atomic unit by using HTTP status codes. For these reasons, the server must first test the UPDATE_CONDITION using an ASK query before issuing an update operation. The ASK query returns a boolean to indicate whether the given WHERE block matches the specified dataset(s). Fortunately, the server can issue multiple ASK queries in parallel, allowing the triplestore to handle load-balancing the queries against separate graphs and reduce the total time spent waiting for query results to determine which commit will be used to apply the update. Depending on several factors, using the read-only ASK operation to search multiple graphs in parallel to find those which satisfy the UPDATE_CONDITION might even outperform the aforementioned update-until-it-works technique, though this is only speculation.

1.2. Effective staging graph