3.2.1 removes `RDF::Repository::Implementation::SerializedTransaction`

[no-reply]

seeing some downstream NameErrors on this.

i gather the hamster driven repository has been moved elsewhere, but am still working on understanding the impact. ActiveTriples has a direct dependency on SerializedTransaction.

at this point, i'm uncertain whether the replacement of RDF::Repository::Implementation::SerializedTransaction with RDF::Transaction::SerializedTransaction will have acceptable properties for ActiveTriples, ldp and their various Samvera dependents, but if so i'd like to suggest that we alias the old name to reinstate compatibility.

[gkellogg]

The hamster impl is on the rdf-hamster-repo gem now, but SerializedTransaction is more generally useful (including for rdf-ordered-repo and the built in implementation). That fact that there is apparently a dependency in ActiveTriples shows this.

rdf-ldp seems to work okay as is, based on the specs passing, anyway.

I’ll create an alias.

[no-reply]

the broken ldp gem is: https://rubygems.org/gems/ldp (client) rather than rdf-ldp (server)

[no-reply]

thanks for your help!

confirming that a release with #430, in the 3.x series will fix the relevant downstream builds.

off the cuff, any guess what i should expect as concerns performance for the new SerializedTransaction implementation? i'm trying to decide whether ActiveTriples needs to add the hamster dependency back, and if so what the best way to inject that as the default repository for its users will be.

[gkellogg]

The SerializedTransaction implementation hasn't changed, it's the default implementation uses regular hashes, rather than Hamster hashes.

The performance implications mostly come down to the relative implementations of #insert_to:

Using Ruby hash:

data          = data.has_key?(c)       ? data.dup       : data.merge(c => {})
data[c]       = data[c].has_key?(s)    ? data[c].dup    : data[c].merge(s => {})
data[c][s]    = data[c][s].has_key?(p) ? data[c][s].dup : data[c][s].merge(p => {})
data[c][s][p] = data[c][s][p].merge(o => statement.options)

Using Hamster:

return data.put(c) do |subs|
  (subs || Hamster::Hash.new).put(s) do |preds|
    (preds || Hamster::Hash.new).put(p) do |objs|
      (objs || Hamster::Hash.new).put(o, statement.options)
    end
  end
end

I haven't benchmarked it.

I'll add both 'ldp' and and active-triples to my local set to run against.

I presume you're good to do a 3.2.2 release of RDF.rb

[gkellogg]

Resolved via #430 and released in version 3.2.2.