Skip to content

Conversation

@no-reply
Copy link
Member

This implements write transactions for RDF::Graph, partially fulfilling #269.

Transactional read scoped to a Graph remains to be implemented.

Tom Johnson added 3 commits February 15, 2016 12:37
Transaction application will apply to Graph, so we are moving related
methods into their own `RDF::Transactable` module.
Allow RDF::Graph to process write transactions.
@gkellogg
Copy link
Member

LGTM other than comment.

Tom Johnson added 2 commits February 15, 2016 14:28
Certain aspects of `#isolation_level` don't apply to snapshots, but to
snapshot + transaction. This peels the two apart somewhat.

`Dataset` & `Repository` handle communicating the isolation level for
`#snapshot`.

The base `RDF::Transaction` defaults to `:read_committed`, but adheres
to the snapshot's semantics if present. Generally, this will mean
`:repeatable_read` or worse.

The default Repository's `SerializedTransaction` assumes a snapshot, and
is always `:serializable`.
@no-reply
Copy link
Member Author

A fix is in for false graph names via 0c1294a.

See also: 3a6762e.

Tests are, likewise, fixed at: ruby-rdf/rdf-spec#56

@no-reply
Copy link
Member Author

One thing to note is that these changes work slightly differently from inserting/deleting statements on a RDF::Graph directly.

graph << statement will overwrite the graph_name. In a transaction context, we will retain an existing graph_name, but add the Graph#graph_name when one isn't present for the statement.

This is roughly how things worked with Changeset in 1.1.x. If we want things to look like regular graph insertion (where, e.g. graph1 << graph2 works) we really need to rethink things.

@no-reply
Copy link
Member Author

Apart from my note about graph_name I think this is ready.

It doesn't close #269 until Transactional graph read is done.

@gkellogg
Copy link
Member

If we want things to look like regular graph insertion (where, e.g. graph1 << graph2 works) we really need to rethink things.

Maybe create an issue to track this. It is fairly useful to do an insert of an enumerable, as is done elsewhere.

gkellogg added a commit that referenced this pull request Feb 15, 2016
@gkellogg gkellogg merged commit f84da9c into develop Feb 15, 2016
@gkellogg gkellogg deleted the feature/graph-transactions branch February 15, 2016 23:42
@no-reply
Copy link
Member Author

@gkellogg you can insert enumerables as usual. The potential sticking point is that if one enumerable emits graph_name for its statements, the Graph will accept it in a Transaction, but replace it otherwise.

An issue is open at: #278

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants