8000 Updates ocfl-java to 1.5.0 by dbernstein · Pull Request #53 · fcrepo/fcrepo-storage-ocfl · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Updates ocfl-java to 1.5.0 #53

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

Merged
merged 2 commits into from
Oct 27, 2022
Merged

Updates ocfl-java to 1.5.0 #53

merged 2 commits into from
Oct 27, 2022

Conversation

dbernstein
Copy link
Contributor

Resolves: https://fedora-repository.atlassian.net/browse/FCREPO-3857

Updates ocfl-java to 1.5.0


JIRA Ticket: https://github.com/dbernstein/fcrepo-storage-ocfl/pull/new/FCREPO-3857

  • Other Relevant Links (Mailing list discussion, related pull requests, etc.)

What does this Pull Request do?

No functional changes.

How should this be tested?

A description of what steps someone could take to:

  • Reproduce the problem you are fixing (if applicable)
  • Test that the Pull Request does what is intended.
  • Please be as detailed as possible.
  • Good testing instructions help get your PR completed faster.

Interested parties

Tag (@ mention) interested parties or, if unsure, @fcrepo/committers

@@ -1637,6 +1638,7 @@ private void assertVersions(final List<OcflVersionInfo> actual, final String...
final var versionNums = actual.stream()
.map(OcflVersionInfo::getVersionNumber)
.collect(Collectors.toList());
sort(versionNums);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Instead of sorting here, you could change the next line to:

assertThat(versionNums, containsInAnyOrder(expected));

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks @pwinckles : I'll change it.

@pwinckles
Copy link
Collaborator

I haven't checked to see if there's been any discussion of this, but after this upgrade ocfl-java will create ocfl 1.1 repositories by default. It will not "upgrade" existing repositories to 1.1 without explicitly asking it to. I'm not sure if you do or don't want to enable users to upgrade the repo. Honestly, I don't think there's really much reason to "upgrade". 1.0 and 1.1 are functionally equivalent.

@whikloj
Copy link
Collaborator
whikloj commented Oct 27, 2022

We haven't discussed that, but I agree and see no reason to upgrade. OCFL being immutable and made for long-term preservation means that items in a repository could (and probably will) contain a multitude of versions.

Copy link
Collaborator
@whikloj whikloj left a comment

Choose a reason for hiding this comment

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

👍

@whikloj whikloj merged commit 08c8ae4 into fcrepo:main Oct 27, 2022
@dbernstein dbernstein deleted the FCREPO-3857 branch October 27, 2022 20:41
@pwinckles
Copy link
Collaborator

We haven't discussed that, but I agree and see no reason to upgrade. OCFL being immutable and made for long-term preservation means that items in a repository could (and probably will) contain a multitude of versions.

After this update, an existing repository would not start creating 1.1 objects. It would still be 1.0 objects only, even new objects. However, newly created repositories would use 1.1 and create 1.1 objects. You can configure ocfl-java to either upgrade existing repositories to 1.1 and create new objects as 1.1 (existing objects remain unchanged), or upgrade the repo and upgrade existing objects when they are next written to. Neither of these upgrade options are enabled by default.

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
0