Data Mapper Working Group Retrospective

Owned by Trey Pendragon
Nov 05, 2017
3 min read

Metrics & Questions

Valkyrie archiecture diagramObjective

  1. Lines of code in Valkyrie vs ActiveFedora

    1. Source Lines of Code (SLOC's)

9.png

  1. ABC Complexity Score

11.png

  1. Performance Comparison between Valkyrie & ActiveFedora

    1. https://github.com/samvera-labs/valkyrie/wiki/Benchmarks

    2. http://awead.github.io/fedora-tests/

  2. Feature Comparison between AF & Valkyrie


Feature

ActiveFedora

Valkyrie

Versioning

find, create, restore (binaries & metadata)

No (open ticket https://github.com/samvera-labs/valkyrie/issues/162 )

Fixity checking

Yes (one algorithm)

Yes (N algorithms)

Assign predicates to properties

Mandatory

Optional for Fedora

Not supported for other backends

Save metadata in Fedora

Yes

Yes

Save files in Fedora

Yes

Yes

Describe files with metadata

Yes

Yes

Relationships

Yes (Rails-style)

Yes (attach IDs)

Nested properties

Possible, but complicated

Yes

Solr indexing

Yes

Yes

Query support

Solr (very flexible)

Predefined queries, can be extended

Derivative support

Yes (Hydra::Works)

Yes (extensible pattern)

Characterization support

Yes (Hydra::Works)

Yes (extensible pattern)

Persist in different backends

Fedora and Solr both required

Multiple independent backends

Ordered relationships

Yes (PCDM or generic)

Yes (member IDs)

RDF support

Yes (required)

No (but supports RDF literals, URIs, links, etc.)

ActiveModel

Yes

Yes (ChangeSets)

Dirty checking

Yes (ActiveModel)

Yes (ChangeSets)


Subjective

  1. Is it easier to understand & contribute to Valkyrie than AF?

    1. Yes. There’s less code, less metaprogramming, and a clearer separation of patterns. However, implementations of the same feature in multiple backends can be complex.

  2. Is it easier to use Valkyrie in an application?

    1. At least initially, Valkyrie has a steeper learning curve because the patterns are different from ActiveFedora/ActiveRecord.  But the simpler, more explicit codebase makes it easier to make changes, trace performance issues, and develop the features you want. The MVP provides a good model to follow.

  3. What’s the comparative maintenance burden?

    1. We feel that Valkyrie may be easier to maintain simply because there’s less code, lower complexity, and there is already a community of developers from multiple institutions who feel like they understand and can contribute to the codebase as it exists. Questions remain about how to handle versioning and compatibility between the various backends as time goes on.

  4. Do the shared specs help with maintenance of a Valkyrie application?

    1. The shared specs have proven in practice to inform application developers about when new features have been added to Valkyrie with newly required interfaces. However, there’s a maintenance burden involved for reviewers in Valkyrie to ensure that they’re maintained.

  5. How hard is it to adopt Valkyrie?

    1. Starting an application from scratch using Valkyrie has proven to be a positive and largely simple experience. However, migrating a large and complicated code-base like Hyrax is a significant effort due to the fundamental pattern differences.

  6. How difficult is it to migrate data into Valkyrie?

    1. Currently this requires either developing a custom adapter to conform to your existing data structure and backend (avoiding data migration) or to write ad-hoc scripts to migrate, which is similar to any migration previously undertaken by the community.

  7. How difficult is it to switch to a new backend with Valkyrie/AF.

    1. A consistent interface makes this very easy: https://github.com/samvera-labs/valkyrie/wiki/Migrate-Between-Adapters

  8. Is it easier to customize indexing in Valkyrie or ActiveFedora?

    1. They have a similar level of difficulty. ActiveFedora relies on overriding a method at the model layer (#to_solr) while Valkyrie depends on configuring a set of indexers (https://github.com/samvera-labs/valkyrie/wiki/Custom-Indexing). Both have been successful at fulfilling the necessary indexing use cases.

  9. Did the working group meet its objectives?

    1. We feel like we’ve met our original objectives:

      1. Enables persistence of metadata into at least two different backends (one being Fedora.)

        1. We support Fedora/Postgres/Solr/In-Memory

      2. Enables persistence of binary resources (files) into at least two different backends (one being Fedora.)

        1. We support Disk/Fedora/In-Memory

      3. Reduce the dependence of Samvera's front-end on inter-community gems, preferring solutions with a larger adoption.

        1. The MVP attempted to do this and was able to use a few more gems from outside the community. Valkyrie itself uses a modeling layer developed by another community (the dry-rb set of gems). However, getting that work distributed through projects like Hyrax will be an on-going effort.

      4. Provides a suite of tests for creating further backends without altering the front-end business logic.

        1. We’ve developed a set of shared specs for R-Spec which have already helped some implementing projects keep up with the library.

        2. https://github.com/samvera-labs/valkyrie#shared-specs

  10. What’s next?

    1. The Data Mapper working group is closing, but there’s still some more work to do:

      1. Develop Migration Strategies

      2. Architecture Discussions

      3. Valkyrie Development & Maintenance Plan

    2. For people using Sufia, CurationConcerns, and Hyrax:

      1. Complete implementation of Hyrax support for Valkyrie

      2. Develop Migration Strategies