This repository was archived by the owner on Apr 16, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 153
Issue #806 Metadata files should have relative paths #807
Merged
ggalmazor
merged 3 commits into
getodk:master
from
ggalmazor:issue_806_metadata_file_with_relative_paths
Sep 10, 2019
Merged
Issue #806 Metadata files should have relative paths #807
ggalmazor
merged 3 commits into
getodk:master
from
ggalmazor:issue_806_metadata_file_with_relative_paths
Sep 10, 2019
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is to be able to serialize just a relative form dir and let the adapter provide the storage root when reading metadata files. This way, we make serialized metadata files portable, since they only have relative paths to the storage root.
dcbriccetti
reviewed
Sep 9, 2019
@@ -55,19 +57,21 @@ public FormMetadataPort syncWithFilesAt(Path storageRoot) { | |||
Stream<Path> formFiles = candidateFormFiles.filter(path -> isAForm(XmlElement.from(path))); | |||
|
|||
// Parse existing metadata.json files or build new FormMetadata from form files | |||
Stream<FormMetadata> metadataFiles = formFiles.map(formFile -> { | |||
// At this point, we collect the stream to avoid problems coming | |||
// from actually writing files in the same folders we're reading from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What sort of problems?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Classic reading stuff that you're writing to. The adapter scans, reads and writes the same files in the same stream.
dcbriccetti
approved these changes
Sep 9, 2019
This doesn't make much sense. What we want is to clean our in-memory repo to allow for new scans
They have to be flushed whenever the user changes the storage location. Otherwise, formdefs or form metadata objects could point to old locations if it happens that a form is present both in the previous and current sds. Use fresh FormStatus list to avoid problems when changing sd locations If a form happens to be both in the previous and current locations, we need to be sure we have a fresh FormStatus with a fresh form definition pointing to the new sd location
Tested with success! @opendatakit-bot unlabel "needs testing" |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #806
What has been done to verify that this works as intended?
Fixed and run the automated tests
Manually pulled forms, changed the sd location, and exported them
Why is this the best possible solution? Were any other approaches considered?
This is the smallest change I could come up to be able to store relative paths while providing absolute paths to downstream code.
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
No risks here, just a fixed bug :)
Does this change require updates to documentation? If so, please file an issue at https://github.com/opendatakit/docs/issues/new and include the link below.
Nope.