error on repo.first.subject in example

[igravious]

…/vendor/cache/ruby/2.3.0/gems/rdf-2.2.11/lib/rdf/model/dataset.rb:67:in each_statement': undefined method each' for nil:NilClass (NoMethodError) from …/vendor/cache/ruby/2.3.0/gems/rdf-2.2.11/lib/rdf/mixin/queryable.rb:172:in first'
from test-store.rb:24:in <main>'

fwiw repo.first_subject works

[gkellogg]

This particular error is in RDF.rb, not rdf-do. The error likely results from an issue in rdf-do originally, but it's shown up in other gems, and RDF.rb should provide a more meaningful error.

This gem has languished and does not pass specs, so it needs more attention.

From the original email:

Though imho this info could feature more prominently in the initial README at https://github.com/ruby-rdf/rdf in the tutorial section in between "Using RDF.rb and Spira to process RDF data from the British Ordnance Survey" and "Getting started with RDF and SPARQL using 4store and RDF.rb"?

Specifically the Using code from https://github.com/ruby-rdf/rdf-do:

require 'rdf'
require 'rdf/ntriples'
require 'data_objects'
require 'do_sqlite3'
require 'rdf/do'

repo = RDF::DataObjects::Repository.new uri: 'sqlite3:test.db'
# repo = RDF::DataObjects::Repository.new uri: 'postgres://postgres@server/database'
# heroku_repo = RDF::DataObjects::Repository.new uri: ENV['DATABASE_URL']
repo.load('http://datagraph.org/jhacker/foaf.nt')

# How many statements did we have?
repo.count
#=> 10

# Get the URI of the first subject
jhacker = repo.first.subject
#=> #<RDF::URI(http://datagraph.org/jhacker/foaf)>

# Delete everything to do with it
jhacker_statements = repo.query(subject: jhacker) 
repo.delete *jhacker_statements
repo.count
#=> 7

# with Postgres, we could have done this, but SQLite gives us a locking error:
# repo.delete(*repo.query(subject: jhacker))

# Changed our mind--bring it back
repo.insert *jhacker_statements
repo.count
#=> 10

Having said that I'm getting an error on repo.first.subject

  …/vendor/cache/ruby/2.3.0/gems/rdf-2.2.11/lib/rdf/model/dataset.rb:67:in `each_statement': undefined method `each' for nil:NilClass (NoMethodError)
      from …/vendor/cache/ruby/2.3.0/gems/rdf-2.2.11/lib/rdf/mixin/queryable.rb:172:in `first'
      from test-store.rb:24:in `<main>'

[igravious]

Is there anything I can do to help bring rdf-do up to spec Gregg?

[gkellogg]

As you might have seen, specs are not passing with essentially the same error you reported. Also, we've never configured Postgress on Travis.

The Statement#to_hash deprecation messages are indicative of calls to an interface that automatically invokes that deprecated interface, due to a **options argument and that the statement is the last argument. Probably best for me or @no-reply to track this down, as it's part of a general update.

As you can tell, this gem has languished, due to general lack of use. Generally, for a simple and more performant option, I use rdf-mongo. I also think that a file-backed (or other persistent store) version of the base RDF::Repository (or similar) would provide great performance and satisfy what you're interested.

That said, we do need to get rdf-do working, so whatever you would like to contribute, in terms of a PR, would be helpful.

In the mean time, I'll track down the DEPRECATION issue, which may solve a bunch of problems.

[gkellogg]

It seems that the problem is because RDF::DataObjects::Repository implements #each, and RDF::Dataset implements #each_statement. The header of RDF::Enumerable says that implementation should implement #each, but when we introduced RDF::Dataset, it implemented #each_statement, instead of #each.

See ruby-rdf/rdf#365.

[gkellogg]

BTW, fixing this allows all but one spec to pass in Sqlite3, that being repository count:

  1) RDF::DataObjects::Repository The SQLite adapter behaves like an RDF::Repository as dataset behaves like an RDF::Dataset when enumerating statements behaves like an RDF::Enumerable when enumerating terms #each_term has correct number of terms
     Failure/Error: DEFAULT_FAILURE_NOTIFIER = lambda { |failure, _opts| raise failure }
     
       expected: 98
            got: 101

I've seen these before in other repos (e.g., rdf-aggregate-repo), and should look there to see how the issue was resolved.

[igravious]

Do you want me to have a go at fixing it, or are you on top of it? I know you that

Probably best for me or @no-reply to track this down, as it's part of a general update.

but if you want me to take a look at it I will.

I'd need to know how to run the specs for rdf-do locally, am unsure how to do that. I'll tell you why I like using the Sqlite back-end rather than a simple file or Mongo. The reason is that when I'm using Rails in dev mode Sqlite is already automatically being used. That means I point th triplestore repo at the dev Sqlite db and have the triples table quad in the same db as the resource table that I use for tracking local resources. Makes sense, no?

Anyway, thanks for following so quickly – as has been my experience with Ruby-RDF in the past 👍

[gkellogg]

I'm giving @no-reply a bit more time to respond to ruby-rdf/rdf#365 (PR ruby-rdf/rdf#366) before I merge it, as he did the RDF::Dataset work. You could either work against that branch, or wait for the merge and then look at the failing spec. It would also be great to get Postgres support working, particularly on Travis, for which there are probably some existing recipes.

Note that DataObjects hasn't been updated in a while, and you'll get numerous warnings when running on a Ruby 2.4 code base, but it functions okay. Unfortunately, the release hasn't had much attention. It may be that it's time to deprecate rdf-do, and simply use the sqlite3 gem directly; same could be done for other database backends, but I don't see evidence for Postgres use with RDF.rb.

[no-reply]

I went ahead and merged #366.

I'm open minded about how to handle bringing this gem up to date and willing to throw some cycles at it if we can get a sense of what would be most valuable to the community.

[gkellogg]

The update to RDF.rb has been pushed, so this gem should work reasonably, other than deprecation messages issued by data_objects (which is way out of date) and the above mentioned error. @igravious if you'd like to track this down, and potentially see about Postgres going on Travis, that would be great.