more powerful ActiveFedora::FixityService #1239
Conversation
jrochkind
force-pushed
the
more_powerful_fixity_service
branch
from
c970e8c
to
184c478
Compare
|
|
||
| # integer, as reported by fedora. bytes maybe? | ||
| def expected_size | ||
| fixity_graph.query(predicate: ::RDF::Vocab::PREMIS.hasSize).first.try(:object).try(:to_s).try(:to_i) |
There was a problem hiding this comment.
Why are you doing to_s.to_i? Isn't the result already an integer?
There was a problem hiding this comment.
Nope, it's an RDF::Literal representing a string.
There was a problem hiding this comment.
I don't know if there's some way to tell the RDF::Graph what it's supposed to be so it comes back as something other than something like what you'd get from RDF::Literal.new("12121212")... but this seems good enough maybe?
There was a problem hiding this comment.
Perfect. Thanks for the explanation.
There was a problem hiding this comment.
does fixity_graph.query(predicate: ::RDF::Vocab::PREMIS.hasSize).map(&:object).map(&:to_base) work here? query is returning a set of RDF::Statement which you can call object. That in turn should be a set of RDF::Term objects, and to_base is supposed to return the base representation of the form.
There was a problem hiding this comment.
@awead No, it doesn't seem to.
fixity_graph.query(predicate: ::RDF::Vocab::PREMIS.hasSize).map(&:object).map(&:to_base)
# => ["\"103945\"^^<http://www.w3.org/2001/XMLSchema#long>"]
The String "\"103945\"^^<http://www.w3.org/2001/XMLSchema#long>" is of course not very useful. I just want 103945 as an integer.
Do you think what's there now which works is acceptable?
There was a problem hiding this comment.
alas, I had hoped to_base might circumvent the first..try..try business. Yeah, it's fine.
| # the currently calculated checksum, as a string URI, like | ||
| # "urn:sha1:09a848b79f86f3a4f3f301b8baafde455d6f8e0e" | ||
| def expected_message_digest | ||
| fixity_graph.query(predicate: ::RDF::Vocab::PREMIS.hasMessageDigest).first.try(:object).try(:to_s) |
There was a problem hiding this comment.
Why is to_s necessary? Isn't the object already a string?
There was a problem hiding this comment.
Nope, an RDF::Literal.
There was a problem hiding this comment.
see my other comment about mapping object and to_base
There was a problem hiding this comment.
#to_base here gives me "<urn:sha1:1a89571e25dd372563a10740a883e93f8af2d146>". I don't really want those angle brackets. I guess I could do that and strip the angle brackets off... but what's here now seems simpler to me. What do you think?
I don't really understand the right ways to interact with the RDF::Graph stuff so appreciate your advice. But I'd also rather not fight with it if what I have here now works fine, unless there are significant problems I don't know about with what I have now?
|
Oh, forgot to mention I also replaced some of the mocked fedora responses in the test with actual responses from my fcrepo 4.7.0, which were quite different than what was mocked before (a different RDF serialization format?), but didn't break any of the existing tests, hooray. |
jrochkind
force-pushed
the
more_powerful_fixity_service
branch
from
184c478
to
5717e1e
Compare
jrochkind
force-pushed
the
more_powerful_fixity_service
branch
2 times, most recently
from
8491899
to
37fa6e6
Compare
| premis:hasSize "1878582"^^<http://www.w3.org/2001/XMLSchema#long> . | ||
| EOF | ||
| } | ||
|
|
There was a problem hiding this comment.
optional, but exceedingly awesome, would be a fixture file with that gets read in here instead of the EOFs
There was a problem hiding this comment.
Are you thinking of a fixture file that just has the text in it, that just gets read in with File.read? Personally, I like having the data right here in the file so a developer can look at it and see exactly what is being tested. I think especially important for a mock of an external serivce I think, where it can easily get out of sync with what the service is actually returning (as I think it had), and it's good for it to be front and center for any developer looking at it.
But it's easy enough to make a fixture file if the consensus is a different opinion?
The fedora fixity service also reports the expected message digest and file size. It makes sense to allow these to be accessed. Actually cache the http response. Comment erroneously implied it was cached before, but it wasn't. #check still forces a new check, as it did before this commit, but verified? is a more clear method name for return value, and will not bust response cache. Cleaned up some erroneous comments.
jrochkind
force-pushed
the
more_powerful_fixity_service
branch
from
37fa6e6
to
53a3ba1
Compare
|
If any new commits are made before I merge, Github makes me merge/rebase master into this branch again before I can click 'merge branch'. And then wait for travis to run again. and then hope nobody else has committed to master, or else I have to do the dance again. Is this a problem for anyone else? If people are making frequent commits, it might become impossible to ever merge, as people make commits in the time it takes travis to run. So tell me now @awead if you'd rather me hold off on this, otherwise I'm merging as soon as I notice travis being done again. :) |
The fedora fixity service also reports the expected message
digest and file size. It makes sense to allow these to be accessed -- might be wanted for reporting/logging, especially on failure.
Actually cache the http response. Comment erroneously implied
it was cached before, but it wasn't. #check still forces a new
check, as it did before this commit, but verified? is a more
clear method name for return value, and will not bust response
cache.
Cleaned up some erroneous comments.