Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

delegate IIIF Manifest cache key version to presenter #4418

Merged
merged 1 commit into from
Jul 10, 2020

Conversation

no-reply
Copy link
Contributor

it turns out etag isn't a very good cache key because the default
SolrDocument doesn't contain this data. using the system/Fedora
#modified_date is equivalent (has the same weaknesses) but is available on
both an actual work instance, and on its index proxy.

since this is changing (and should likely change again!), delegate it to the
presenter so there's a clear source going forward.

@samvera/hyrax-code-reviewers

it turns out `etag` isn't a very good cache key because the default
`SolrDocument` doesn't contain this data. using the system/Fedora
`#modified_date` is equivalent (has the same weaknesses) but is available on
both an actual work instance, and on its index proxy.

since this is changing (and should likely change again!), delegate it to the
presenter so there's a clear source going forward.
it 'returns a string' do
expect(presenter.version).to be_a String
end

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worthwhile to add a test here showing that it updates when the work updates? Maybe something like this?

it 'changes when the work changes' do
  expect { work.save }.to change { presenter.version }
end

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a PR for this spec. If @no-reply likes it, we'll add it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see discussion at #4421 (review)

@no-reply
Copy link
Contributor Author

since the backport (#4419) is in, i think we should either merge this as-is and roll forward or revert the backport in 2.x-stable

the current state of the branches is out-of-line with our branching approach, so we shouldn't let it remain for long.

@cjcolvar
Copy link
Member

I'm fine with not holding this up over the suggested test.

@no-reply no-reply merged commit 679ac19 into master Jul 10, 2020
@no-reply no-reply deleted the manifiest-cache-key branch July 10, 2020 17:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants