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

Link to OCDS Merge test cases if merged releases present #54

Open
jpmckinney opened this issue Sep 2, 2020 · 1 comment
Open

Link to OCDS Merge test cases if merged releases present #54

jpmckinney opened this issue Sep 2, 2020 · 1 comment

Comments

@jpmckinney
Copy link
Member

Add a note to the Headlines like: "This file contains compiled releases [and versioned releases]. If you created these merged releases, we encourage you to test your implementation of the merge routine using the OCDS Merge test cases. For assistance, please contact the OCDS Helpdesk."

Moved from OpenDataServices/cove#1210

@jpmckinney jpmckinney changed the title OCDS: Link to OCDS Merge test cases if merged releases present Link to OCDS Merge test cases if merged releases present Sep 2, 2020
@jpmckinney
Copy link
Member Author

jpmckinney commented Jan 5, 2021

Additional context, from document in #101:

Merge strategies validation + explanation, i.e. check whether the record(s) in the supplied data are the product correctly merged releases. Would want to limit to embedded releases, at least initially, to avoid performance and network issues.

Similar UI to additional fields / missing fields.

  • James: I'm not sure I can correctly imagine what the UI will look like. Do you expect to report the specific differences between the expect and actual compiledRelease? What if we do one iteration just reporting the fact that they differ?
  • Rob: I think we'd expect to list out the things that are present but shouldn't be, or are missing but should be present in the compiledRelease. We can certainly indicate that they differ with a first iteration, and that'll be relatively easy, it's whether that's sufficient to be useful.
  • James: I think it's more complicated than reporting presence/absence. If the releases imply that tender.period is a given value, but the compiledRelease is reporting a different value, that's an error. But then you're essentially reporting a diff.
  • Rob: we think the JSON merge patch tooling could give us a useful diff to make available

James: Before going the extra step and working on a clean, useful diff to present to users, we should: (1) identify the publishers using records; (2) check if any of their records produce this error; (3) get a sense of why that might be – in order to design an appropriate solution in the validator

My comment from this report:

As discussed elsewhere [i.e. above], not clear what feedback can be given besides "your compiled release differed from the expected compiled release: here is the diff".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant