bad behaviour in RDF::List

[doriantaylor]

I recently noticed while working on a project that initializing an RDF::List tends to write to the graph, and with the current set of parameters to the constructor, it appears to be very difficult to get it to not do that.

Ideally I would like a constructor to which I could pass what I suspect to be the head of an existing list and it reads the graph and slurps up the rest of it in a way that I can guarantee will not modify the existing graph. The current constructor appears to have a bias toward modifying, so I'm proposing either adding something like a :no_mutate flag to the current constructor, or creating a new constructor (I sketched one out elsewhere), or both. I have some time now so I can look into it; just registering the issue here.

[gkellogg]

It should be the case the it only modifies the graph when initialized with values, or when one of the methods which specifically adds or removes entries is called. Perhaps we need tests to verify this behavior.

Do you have an example which shows it modifying the graph?

[doriantaylor]

I'll dig one out in a bit…

[doriantaylor]

Ah, okay, looking at the constructor a little more closely: my understanding is if you want to retrieve an existing list from the graph, you pass it the graph: and the subject: which is supposed to be the bnode at the head of the list, and do not pass it any values:, and the list's contents won't get retrieved until you call #to_a.

Reading the code for RDF::List it seems like it's "lazy to read, eager to write", like it's very easy to spur it into making changes to the graph when that might not have been what you wanted.

I think if I were to design an rdf:List implementation I'd be inclined to bias it the other way: you pass the head of the list to the constructor (along with the repo) and it eagerly slurps up and validates the entire thing, and then stores a representation of it internally along with its corresponding bnodes. Any modifications you make to the list do not get published back to the graph until you do something analogous to applying a changeset. (This would also have the added benefit of making RDF::List manipulations more transactable.)

[gkellogg]

Might have some other side-effects, such as caching a value of a list when in the process of modifying the underlying graph, but that might not actually get triggered.

Arguably, graphs shouldn't be mutable at all (and datasets aren't, in fact), but mutating operations should always just yield another graph/repository, but that would break a bunch of contracts.

If you're up for it, why don't you try to implement it your way and see if it passes all the tests. This code mostly pre-dates my involvement.

Also be good to get @no-reply's opinion, or any other lurkers.

[gkellogg]

Probably the best thing is to wrap list operations in a transaction, which can either be committed or aborted.

I'm working on a wrap_transaction option to the List initializer, which will create transaction around the callback, which should do what you want. You can then either commit or abort the transaction to either apply changes atomically or have no writes at all go back to the base graph.

Creating an internal cache for the list and isolating all operations to that cache and requiring a separate commit operation would require more of an extensive rewrite to the class, but could have some performance advantages at the potential for losing changes and having operations not be consistent across other graph queries.

Note that the Notation-3 gem implements RDF::N3::List, which is cached, as in N3, lists are first-class objects, but it's not compatible with repositories that aren't specifically designed to implement it.

[gkellogg]

@doriantaylor Let me know if this satisfies your needs; otherwise, we can keep it open for a more extensive change later.

[gkellogg]

I'm going to close and release this change. We can always re-open or create something else in the future.