Update of fixity infrastructure in order to be able to create Fixity results for projected Datastreams #195
Conversation
| final Collection<FixityResult> blobs = | ||
| runFixityAndFixProblems(datastream); | ||
| Collection<FixityResult> blobs; | ||
| if (datastream.getNode().isNodeType(FedoraJcrTypes.FEDORA_PROJECTION)) { |
There was a problem hiding this comment.
We have to mix fedora:projection in because Modeshape doesn't give us a way to find out where a binary stream actually comes from?
There was a problem hiding this comment.
Could we use org.modeshape.jcr.value.binary.ExternalBinaryValue to our advantage, somehow?
There was a problem hiding this comment.
Right, I didn't find another way to determine whether a node is projected.
There was a problem hiding this comment.
So implementation would be ExternaBinaryValue for projected nodes and StoredBinaryValue for normal nodes? I'll check that...
There was a problem hiding this comment.
If that works, while you're at it, I think there's also InMemoryBinaryValues, which can't be repaired either.
|
I'll take a look at the comments and see what can be done. |
ghost
assigned 
…cks to happen on e.g. projected nodes that may or may not have our custom fixity properties
…ust created the object; if it already exists, just roll it with it.
Binary values Previously, getFixity only supported binary values that were persisted into a CacheStore, ignoring projected and in-memory values. This patch adds support for InMemory and External values by running their InputStream through our fixity checks (and assumes these values can't be repaired, as some configurations of cache stores can).
As per discussion on Friday, this branch adds a CacheEntry interface, to decouple fixity calculation from the LowLevelStoreService and LowLevelCacheEntry.
Determination of whether nodes are projections now happens using an instanceof ExternalBinaryStoreValue as suggested by @cbeer