Skip to content
This repository was archived by the owner on Apr 16, 2022. It is now read-only.

Issue #806 Metadata files should have relative paths #807

Merged
merged 3 commits into from
Sep 10, 2019
Merged

Issue #806 Metadata files should have relative paths #807

merged 3 commits into from
Sep 10, 2019

Conversation

ggalmazor
Copy link
Contributor

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.

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.
@ggalmazor ggalmazor added this to the v1.17.0 milestone 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
Copy link
Contributor

Choose a reason for hiding this comment

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

What sort of problems?

Copy link
Contributor Author

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.

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
@kkrawczyk123
Copy link
Contributor

Tested with success!
Verified on Ubuntu, MacOS and Windows.

@opendatakit-bot unlabel "needs testing"
@opendatakit-bot label "behavior verified"

@ggalmazor ggalmazor merged commit ba33949 into getodk:master Sep 10, 2019
@ggalmazor ggalmazor deleted the issue_806_metadata_file_with_relative_paths branch September 10, 2019 12:19
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Metadata files should contain relative file paths
4 participants