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

Display UPP identifiers in the output. Little bit of optimising query #20

Merged
4 commits merged into from
Oct 11, 2017

Conversation

ghost
Copy link

@ghost ghost commented Oct 9, 2017

No description provided.

NewModelIdentifiers neoIdentifier `json:"newModelIdentifiers"`
OldModelTypes []string `json:"oldModelTypes"`
OldModelIdentifiers neoIdentifier `json:"oldModelIdentifiers"`
UUID string `json:"UUID"`
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be "uuid" to be idiomatic json?

OldModelIdentifiers neoIdentifier `json:"oldModelIdentifiers"`
UUID string `json:"UUID"`
Types []string `json:"types"`
Identifiers neoIdentifier `json:"identifiers"`
Copy link
Contributor

Choose a reason for hiding this comment

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

Logically identifiers would represent multiple ids? Not just one neoIdentifier? If neoIdentifier as a struct represents more than one id, that should be called neoIdentifiers instead

Copy link
Author

Choose a reason for hiding this comment

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

Yeah, agreed. Hangover from the previous model.

RETURN canonical.prefUUID as prefUUID, p.uuid AS UUID, labels(p) AS oldModelTypes, labels(p) AS newModelTypes,
{labels:labels(ids), value:ids.value} AS oldModelIdentifiers,
{labels:labels(leafId), value:leafId.value} AS newModelIdentifiers
MATCH (p)-[:IDENTIFIES]-(ids:Identifier)
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this no longer required to be a Concept?

Copy link
Author

Choose a reason for hiding this comment

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

The Concept constraint is defined in the first line of the query, so it's not needed again.

@@ -208,6 +195,10 @@ func mapAuthorityToAuthorityProperty(authority string) string {

func mapAuthorityToIdentifierLabel(authority string) (label string) {
switch authority {
case UP_AUTHORITY:
Copy link
Contributor

Choose a reason for hiding this comment

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

This should probably be a map

Copy link
Author

Choose a reason for hiding this comment

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

There's no performance improvement by changing it to a map, and I think this is slightly more readable than defining the map and then doing the lookup.

Copy link
Contributor

Choose a reason for hiding this comment

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

Disagree - you're doing a key value lookup, which is exactly what maps exist for. Adding new mappings will require 2 lines for the constants, plus an addition to this switch statement, which is inefficient

return expected.Concordance[i].Concept.ID < expected.Concordance[j].Concept.ID
})
sort.Slice(expected.Concordance, func(i, j int) bool {
sort.SliceStable(expected.Concordance, func(i, j int) bool {
Copy link
Contributor

Choose a reason for hiding this comment

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

Not sure I like this duplication for expected and actual concordance sorting, but can't offer an alternative (that doesn't involve implementing sort.Interface on Concordances in 3 diff ways)

Copy link
Author

Choose a reason for hiding this comment

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

I've extracted it so at least it's not repeated for both slices.

@coveralls
Copy link

Coverage Status

Coverage decreased (-1.6%) to 41.341% when pulling e612a10 on show-upp-identifiers into dfa8d69 on master.

@ghost ghost requested a review from scott-ace-newton October 10, 2017 10:08
assert.True(t, reflect.DeepEqual(expected, actual), fmt.Sprintf("Actual aggregated concept differs from expected: Test: %v \n Expected: %v \n Actual: %v", testName, expected, actual))
}

func fullConcordanceSort(concordanceList []Concordance) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This is nitpicky but fullConcordanceSort should be simpler (i.e. sortConcordances). Naming it full implies theres another alternative sort func that could be used, but there isn't one.

@coveralls
Copy link

Coverage Status

Coverage decreased (-1.6%) to 41.341% when pulling c9cb94a on show-upp-identifiers into dfa8d69 on master.

@ghost ghost merged commit 6cffb26 into master Oct 11, 2017
@ghost ghost deleted the show-upp-identifiers branch June 21, 2018 15:52
This pull request was closed.
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.

None yet

3 participants