Frequently Asked Questions
Valkyrie is a gem which uses the Data Mapper pattern (https://en.wikipedia.org/wiki/Data_mapper_pattern) to abstract out interaction with metadata and file storage backends, restricted to the use cases of a digital repository. The goal is to enable institutions to share front-end or middleware code, but still make a choice that matches their institution’s needs around where to store their metadata and files on the backend.
Tutorials can be found here: https://github.com/samvera-labs/valkyrie/wiki
-
Choice
Valkyrie allows applications to use a variety of different backends for metadata and file storage depending on their institution’s use cases.
-
Community Inclusion
Valkyrie enables institutions to share logic independent of where they need to store their metadata or files. This results in more shared code in a wider variety of layers and allows institutions to participate in community development no matter their backend decisions.
-
Simplicity
Valkyrie resources are populated the same way independent of which backend they are populated from. This means if you persist to multiple backends (Solr & Fedora for instance), you can use the same code to interact with that object no matter where the object comes from. This has the effect of simplifying front-end code which needs to use one over the other.
-
Performance
While Valkyrie doesn’t inherently provide performance improvements, if performance is necessary an institution can choose an adapter which meets their requirements and migrate to it easily. To enable that decision, benchmarks can be found here: https://github.com/samvera-labs/valkyrie/wiki/Benchmarks
https://github.com/samvera-labs/valkyrie/wiki/Supported-Backends
No, Valkyrie is a middleware layer (like ActiveFedora) for metadata and file access/storage. Neither have UI components, but applications such as Hyrax can use them and front-end features can be provided there.
No, IIIF manifests are a front-end concern and Valkyrie doesn’t provide any features related to it. However, applications have used the Valkyrie models and the iiif_manifest gem to generate IIIF manifests.
No, you can use Fedora with Valkyrie.
It may not be worth the time investment to do the upgrade, assuming you’re not already planning on a major change in your infrastructure. However, the Data Mapper Working Group has found a few points about Valkyrie which may influence your decision:
-
Performance with Valkyrie has shown to be better for Fedora, largely because there’s adapters which gets rid of a lot of middleware that ActiveFedora depends on.
-
The consistent interface between multiple backends often leads to a simpler application.
-
If you’re forced to migrate because of other concerns, migrating to Valkyrie may be just as easy as migrating to another version of ActiveFedora, for example.
-
We believe that the data mapper pattern should make migration easier in the future by separating the abstract representation of the models from where it’s persisted.
Yes! The Hyrax platform has explored several approaches to supporting Valkyrie as its persistence layer. Progress on Valkyrie support as a feature of the platform and adoption plans will be a topic of discussion at Samvera Connect 2018.
Valkyrie Resources have no opinion about RDF predicates and the schema or structure you choose to use. Valkyrie Adapters may allow for a configurable schema which will be applied when it’s saved.
Yes, as of version 1.2! Documentation can be found here: https://github.com/samvera-labs/valkyrie/wiki/Using-Types#ordering-values
Valkyrie has no opinion on the schema you use. However, there is support for arbitrarily deep ordered members, which can be persisted as PCDM by an adapter.
https://github.com/samvera-labs/valkyrie/wiki/Migrate-Between-Adapters
- S3
- There is no storage adapter for Amazon S3 yet.
- EC2
- Valkyrie should run fine on an EC2 instance.
- RDS
- Valkyrie hasn’t been tested with Amazon RDS, but it may work with the Postgres adapter.
There are three storage adapters currently: Fedora / On-Disk / In-Memory.
File IDs contain information about which adapter they were generated with, so you can store references to files from different places on a single object (IE, derivatives on disk and original files in Fedora.) Tutorial: https://github.com/samvera-labs/valkyrie/wiki/Storage-&-Files
Yes.
Valkyrie has a Valkyrie::CompositePersister for making two persisters from two different adapters look like one, but persist to both.
Tutorial: https://github.com/samvera-labs/valkyrie/wiki/Persistence#saving-to-two-backends
Any of the adapters will work, and some may be better than others depending on your use cases. The only general guidance and support we can offer come in the form of benchmarks for each of the adapters: https://github.com/samvera-labs/valkyrie/wiki/Benchmarks
Valkyrie is not inherently faster. It’s an abstraction layer on different persistence engines, and abstraction layers are slower than just using the tool. However, it gives us the option of choosing a faster backend if performance is the most desired feature.
The goal is to use these shared interfaces to support more institutions with varying use cases. We can have a larger community.
Yes.
Files returned from Storage Adapters can have their checksums generated and checked. Details are here: https://github.com/samvera-labs/valkyrie/wiki/Storage-&-Files#calculate-and-verify-checksums
Only Postgres, Fedora, Solr, and in-memory are supported at this time. We have no plans for further adapters to include with the gem, but there are shared specifications to create another one.
If you need advice or support you can create an issue in the Valkyrie repository: https://github.com/samvera-labs/valkyrie/issues
The Data Mapper Working Group has put a lot of thought and revisions into standard interfaces with shared tests that applications can rely on. We believe those trustworthy interfaces will make for easier maintenance.
This is early days, and one never knows how long a library will last, but:
- Valkyrie provides an interface for applications to build around. There’s a lot of thought towards providing clear, testable interfaces for applications to trust.
- The codebase is relatively small. The gem consists of roughly 4,100 lines of code.
- A set of adapters we expect to be used most often have been embedded in the gem, so that those adapters must work in order for the gem to be released. This way we can ensure the most commonly used adapters remain maintained.