Valkyrie Q&A

Owned by Kate Lynch
Oct 25, 2019
5 min read

How do we benchmark Valkyrie?

Do you have a plan for what the next adapters will be? If I want one, could I open a ticket?

  • There are no specific plans for another adapter to go into core Valkyrie. One of the points of Valkyrie is that it's easy to maintain and each new adapter we add, adds complexity to the stack. Every sprint, the retrospective reflects "this was fine, but it might start getting unwieldy if we do this again."
  • Princeton is using Valkyrie-Sequel to interact with Postgres. It's not in core but might be there eventually.

Is anyone tracking where custom adapters outside of Valkyrie are?

Why would you want to write and read as opposed to read only or write only adapters?

  • Use cases: https://github.com/samvera/valkyrie/issues/598
  • Write only: the immediate use case is Solr. I need to put the latest version of a resource into Solr and pull it out. This is tough in Solr currently as it only supports strings and shouldn't be considered a data store. Most Solr use cases are specifically to support Blacklight implementation. Hopefully a standard interface for this would ultimately support things like Elastic Search or triplestores. This is being prototyped currently in the Hyrax on Wings work. There's a certain strength to offering this in the same library.
  • Read only: "I have a weird data store I'm trying to move away from. It's complicated to implement read/write and I don't need write, so I'm going to just use read." Implement methods to allow data extraction ( find_by and find_all ) from one metadata adapter to another.
    You can have a read-only adapter and a write-only adapter for a specific data store and keep them abstracted.

Where does RDF and Linked Data sit in the Valkyrie space?

  • It sits elsewhere. Part of the design of Valkyrie is that we're modeling things specifically as opposed to using a general modeling language like RDF. If you want to support RDF, you can use a backend like Fedora, or implement it elsewhere in your application.
  • The idea is that the Valkyrie resource has no idea about a Linked Data implementation, but you can serialize the data to an adapter that supports RDF.

Is the Valkyrie schema public?

If you have read- or write- only adapters, we could theoretically go easily between data stores? As people do their work?

  • You could persist new objects only to the new data store, and move the items from the legacy store in chunks.
    Adapter container -     https://github.com/samvera/valkyrie/blob/590e52e87231078ea2e130045c89de64d3d3cb7c/lib/valkyrie/adapter_container.rb
  • You can use this to wrap an individual persister and query service for this workflow.
  • Use case: PSU had been using Valkyrie for CHO (https://github.com/psu-libraries/cho), project now on hold. Not using Valkyrie for new project because it's not easy to attach to different projects. How could we improve? Write generators? Good tutorials? Reach out to the greater community?
  • There are Ruby developers outside of Rails using patterns that are quite similar to Valkyrie. It is built on solid, well-established libraries and patterns in the Ruby community. Consider hiring developers interested in Ruby, and not necessarily Rails all the time. These use cases are not a problem that only libraries are dealing with.
  • Hiring - flipping the job posting to focus on this tells people "oh, I can translate based on my experience with data-driven design." which brings in more strong applicants.

What are the next big things for Valkyrie? Versioning and transactions have been discussed.

  • Versioning - a long-open ticket: https://github.com/samvera/valkyrie/issues/162
    • We just don't know what the requirements are for versioning with an API. We don't know who wants this, and how they want to implement it. The ticket is very detailed and we invite discussion on this.
    • PALCI grant has versioning as one of the criteria in the document. This represents a consortial, concrete need.
    • CHO had a use case: versioning files and metadata. If we save a new version of the metadata, we can be aware of the changes. A gem that does something like this - https://github.com/paper-trail-gem/paper_trail
    • Does versioning belong specifically in Valkyrie, or is it easy enough to do elsewhere? Yale has a similar use case for migrating versioned data from legacy systems.
  • Transactions - https://github.com/samvera/valkyrie/issues/678
    • Custom queries in Valkyrie is a great point of extension for unique transactions.
    • Transaction adapters could throw an error for persisters that don't support the custom query.
    • No real timeline for this, but it could be implemented with a relatively light lift. No other real features planned currently. I like Valkyrie!
    • The attention that has been paid to not making breaking changes is invaluable and kept the project sustainable.  We have discussions regularly, "great, how do we implement that without breaking the API?"
    • The current version of reform for changesets is at its final version. Unsure how we will proceed. If we need a new major version when the new thing for changesets comes out, we'll deal with it. If we need to implement changesets natively, we can do that.

Can you talk about the Shrine storage adapter?

If I wanted to find an object in the Rails console, is the plan that Valkyrie will implement Valkyrie query services and not the ActiveRecord-like methods such as where ?

  • Yes, essentially. This is how it's implemented in Figgy, and it looks similar in various pieces of the stack.
  • There is the concept of a wayfinder in Figgy (https://github.com/pulibrary/figgy/blob/ff45412505032cdee22b969b3740c064701f1b9c/app/wayfinders/wayfinder.rb) that can cut down on the length of syntax and preserve relationships between adapters. This could be a good thing because you need to be explicit about the adapter(s) you use, and if you need to change it, you can just update the shortname your wayfinder is registered under, and your code works.
  • In CHO, they originally wanted this, but it's difficult to implement where with multiple data stores, because they're all different. Fedora for example can't do this. CHO did this for their use case because they were specifically using Postgres. So you can choose do implement this in your code but it would be arbitrarily complex to implement straight in Valkyrie.
  • find_by_property exists to channel custom queries in Valkyrie, but this really only works with Postgres.

What do you think about adding syntactic sugar like all , where , and last , either to Valkyrie or to a sidecar gem?

  • Of two minds - by relying on that, your code will immediately be less flexible. How do you do a migration if your code is based around, for instance, .all? Am I going to bring in developers who don't know the internals of Valkyrie and end up confused and/or scared because they're used to ActiveRecord-like methods?
  • On the other hand, if the product owner identifies a real need in the community to do this, that could sway the tide. Decisions like this have been made in the past for the community. Would prefer to try as a sidecar gem first, but if that's necessary, maybe it should just go into the Valkyrie gem.
  • Another alternative would be to implement the syntactic sugar but log warnings that this will make migration more difficult.