pkiraly/metadata-qa-api

calculator.getHeader() returns extractable fields twice

Closed this issue · 5 comments

mielvds commented

Calling calculator.getHeader() on input like:

{"recordId": "0000008c000a4b2cb90eefb7b131289d728fc57cc25946c2aca6ccb0820857da69f1ef620c2b4c99a668cb38062bf45c", "MDProperties.sp_name": "w1", "MDProperties.CP": "orgX", "MDProperties.PID": "2b8vb0bn5z", "MDProperties.dc_identifier_localid": "BR0000035282129", "MDProperties.CP_id": "OR-xxxxx", "MDProperties.dc_title": "BR0000035282129.tif"}

returns "recordId" twice, which makes it invalid as a (csv) header.

Schema:

fields:
  - categories:
      - mandatory_if_present
    name: recordId
    path: $.['recordId']
    extractable: true
format: json
pkiraly commented

@mielvds Could you check if the changes solve it? I used your data as test case, and I was able to reproduce it in another context as well.

mielvds commented

@pkiraly did you update the sonatype artefact? Should we start using semantic versioning more so these kind of fixes become 0.8.X?

pkiraly commented

@mielvds Yes, I did. Could you give me a link about semantic versioning? I like the idea, but I would like to learn more about it. Two questions seems to be the most relevant:

  • Does it mean that there will be no more snapshots?
  • Can a dependent library can refer the API as 0.8.x, which means the latest of 0.8.0, 0.8.1 etc.? Or when we issue say 0.8.3 we should update the dependent project's pom?
mielvds commented

@pkiraly Yes, it works now! I removed my work around from the CLI.

@mielvds Yes, I did. Could you give me a link about semantic versioning? I like the idea, but I would like to learn more about it. Two questions seems to be the most relevant:

The main reference is here: https://semver.org/ Semantic Version doesn't really say anything about using snapshots; it sets rules on the version numbering. I think your already partially applying it btw.

* Does it mean that there will be no more snapshots?

I would certainly still use shapshots for untested releases! But they would change versions more often than they do now.

* Can a dependent library can refer the API as 0.8.x, which means the latest of 0.8.0, 0.8.1 etc.? Or when we issue say 0.8.3 we should update the dependent project's pom?

Depends on what maven can do... AFAIK versions have to be exact. But I think it makes sense that dependent projects update their POM when changes are introduced. This prevents accidentally breaking something.

mielvds commented

btw, there are some maven plugins that might make implementing semver easier: