Expect an error to be raised if trying Repository#transaction

[gkellogg]

when the repository does not support transactions.

[gkellogg]

Goes with ruby-rdf/rdf-spec#53

[no-reply]

I would need to look at this again, but I'm thinking this is heavy-handed.

#supports?(:transactions) is meant to indicate whether transactions are atomic or not. All implementations can/should support changeset based transactions. See: https://github.com/ruby-rdf/rdf/blob/develop/lib/rdf/transaction.rb#L7-L21

I don't think a typical Repository implementation should have to do anything to get this level of support.

[no-reply]

To clarify: the whole contract required for write-atomic transactions via the default RDF::Transaction (#supports?(:transactions) => true) is an atomic implementation of #apply_changeset.

Mutable provides a default implementation that is not write-atomic. Repositories inherit this by default, so non-atomic write transactions come for free.

[gkellogg]

Okay, then supports?(:transactions) doesn't seem right; maybe it should be supports?(:atomic_transactions). The problem came up with immutable repositories, so maybe the check should be skipped unless the repository is mutable?.

[no-reply]

Okay, then supports?(:transactions) doesn't seem right; maybe it should be supports?(:atomic_transactions).

👍 to this.

What is the context for the immutable repository? Any way we can get away with making it a Dataset?

[no-reply]

If Dataset is a non-starter, raising an error when trying to open a writable transaction on a non-mutable could be a more precise solution.

[gkellogg]

rdf-aggregate-repo is an immutable repository, but it could probably be changed to be a Dataset.

[gkellogg]

Yes, raising an error when trying to create a mutable transaction on an immutable Repository makes sense. As mutablility/writability is specifically implemented using Mutable and Writable mixing we should honor implementations that use the ability to say that it is immutable/unwritable.