cul/ldpd-hyacinth

Fedora3 Adapter Implementation

Closed this issue · 7 comments

elohanlon commented

See: /lib/hyacinth/adapters/preservation_adapter/fedora3.rb

We need to implement the persist_impl method, which accepts a location_uri (format will be "fedora3://" + pid) and a digital_object (any subclass of DigitalObject::Base, like DigitalObject::Item or DigitalObject::Asset).

The persist_impl should use Rubydora to serialize the digital_object instance to Fedora 3. Note that the Fedora3 class has instance variables @url, @user, and @password, which should be used to connect to Fedora 3.

We also need to implement the generate_new_location_uri so that it mints new pids and returns uris of the format #{self.uri_prefix}#{newly_generated_pid} (i.e. "fedora3://abc:123").

For some minimal serialization requirements to start, it would probably be most useful to be able to create new Fedora objects when the location_uri (/pid) doesn't exist yet, and write to Fedora objects that do already exist. Let's also write JSON.generate(digital_object.to_serialized_form) to a versioned datastream on these objects with a dsid of hyacinth_data.

barmintor commented

I am looking at the unimplemented method for generating a new location uri:

        # Generates a new persistence location for the given identifier, ensuring that nothing currently exists at that location.
        # @return [String] a location uri
        def generate_new_location_uri(identifier)
          # TODO
        end

Is identifier a string? A uuid? We had talked about porting the pid minter, but that seems unnecessary if the id is received - or is it supposed to create a stub object?

elohanlon commented

That's some copypasta starter code, based on another (non-preservation) adapter. That generate_new_location_uri method shouldn't have any parameters and we should go with what we talked about with the pid minter method.

barmintor commented
barmintor commented

I think two things remain: RelsInt and integration testing (all the testing is against mocks right now, and I wanted to wait before I started running a pocket Fedora).

RelsInt: in Hyc2, we store file size as extent (and I think we index this to help download UI in some places?). I don't see this in Hyc3 - should we a) drop it b) make is a Resource attribute or c) add a bytesize_for method to StorageAdapter?

I've ported the restriction rels, and the checksum bit should be pretty straightforward.

elohanlon commented

My preference is B, making file_size a Hyacinth::DigitalObject::Resource attribute. I want this to be a pre-recorded value that we can validate later on, rather than reading the value live via StorageAdapter.
And you're right that it's used in the download UI.

barmintor commented

ok, those changes are in the branch. I had to do some reimplementation of ResourceAttributes... it was weird. I don't think the Resource objects belong on the class, but I can revert that if necessary.

changing from 'content' to 'master' is going to be a pretty big change downstream (and a big migration). Onward and upward, tho. I'll work on getting integration testing going next.

barmintor commented

fixed when #103 is merged