-
Notifications
You must be signed in to change notification settings - Fork 43
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
entities with same name #1528
entities with same name #1528
Conversation
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.
Thank you for working on this! I have some feedback about some of your tests, and a suggestion for the message being logged.
src/export/CodeSystemExporter.ts
Outdated
if ( | ||
this.pkg.codeSystems.some(cs => cs.name === fshDefinition.name) || | ||
this.pkg.instances.some(instance => fshDefinition.name === instance._instanceMeta.name) || | ||
this.pkg.profiles.some(prof => fshDefinition.name === prof.name) || | ||
this.pkg.extensions.some(extn => fshDefinition.name === extn.name) || | ||
this.pkg.logicals.some(logical => fshDefinition.name === logical.name) || | ||
this.pkg.resources.some(resource => fshDefinition.name === resource.name) || | ||
this.pkg.valueSets.some(valueSet => fshDefinition.name === valueSet.name) | ||
) { |
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.
I think it would be possible to write this condition by checking this.pkg.fshMap
rather than each of the package's lists of FSH entities individually.
src/export/CodeSystemExporter.ts
Outdated
this.pkg.resources.some(resource => fshDefinition.name === resource.name) || | ||
this.pkg.valueSets.some(valueSet => fshDefinition.name === valueSet.name) | ||
) { | ||
logger.error(`Multiple FSH entities created with name ${fshDefinition.name}.`); |
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.
For the message, it might be useful to rephrase it so that it gives some more details about name overlap. Maybe something like "Cannot export [entity type] [name]: an [entity type] with this name already exists." Also, it would be useful to include the source info for the entity that can't be exported.
test/export/InstanceExporter.test.ts
Outdated
expect(loggerSpy.getAllLogs('error')).toHaveLength(0); | ||
expect(loggerSpy.getAllLogs('error')).toHaveLength(1); | ||
expect(loggerSpy.getMessageAtIndex(0, 'error')).toMatch( | ||
/Multiple FSH entities created with name/ | ||
); |
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.
I'm a little confused by this. Why is this error appearing for these tests? There don't appear to be any entities with the same names defined.
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.
This error is occurring for a different reason than below.
Stepping through this test, I see that when export is called in this group of tests, it adds the profile (CarProfile) and the logical (Car) at the same time, so when calling export for the Logical, its already in the this.pkg.FshMap when it checks for it, and throws the error.
test/export/InstanceExporter.test.ts
Outdated
@@ -2217,7 +2248,7 @@ describe('InstanceExporter', () => { | |||
thisIsName.isInstance = true; | |||
thisIsSeacow.rules.push(thisIsName); | |||
const exported = exportInstance(thisIsSeacow); | |||
expect(loggerSpy.getAllMessages('error')).toHaveLength(0); | |||
// expect(loggerSpy.getAllMessages('error')).toHaveLength(0); |
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.
I think this should still be producing 0 errors.
test/export/InstanceExporter.test.ts
Outdated
expect(loggerSpy.getMessageAtIndex(1, 'error')).toMatch( | ||
expect(loggerSpy.getMessageAtIndex(7, 'error')).toMatch( |
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's causing the six additional errors here?
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.
I believe the extra error messages were due to how this test was calling exportInstance multiple times (exportInstance is defined as a function in the beforeEach that when called, calls export for cs, vs, and sd and the instance given) so on the second time, it logged the errors. I adjusted this test (and the one above) to just call export within the function instead.
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.
Thank you!
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.
I think this is a good approach and the code/tests look good.
My one question is if duplicates really need to be errors or if they can be warnings instead. I've reviewed the FSH specification and it does not say that item names need to be unique. The FHIR spec explicitly states that item names do not need to be unique. For these reasons, I'm inclined to say this should be a warning. @KaelynJefferson, @mint-thompson, @jafeltra -- what do you think?
If the team decides that error is appropriate, then I would like to run a regression to see if it causes new errors for existing projects -- and if so, to what degree.
UPDATE: I ran the regression and this caused new errors in almost 60 projects of out the 510 projects updated in the last year (so... > 10% of projects are affected). That being the case, I don't think we want to introduce this as an error. And if we make it a warning, we might want to consider some additional guidance on how you can make the entity name unique while retaining the same name in the exported definition (as it seems that people must be doing this intentionally). |
@KaelynJefferson: The rest of the team discussed this in a standup and agreed that we don't want this to be an error. We also thought that logging 50 warnings (as would be the case for a few IGs) might be too much. So we suggest that you collect all of the duplicate entity names and issue one warning message. Perhaps something like:
|
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.
I've made a small request for a change. In addition, I think this needs to be re-synched with the master branch.
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.
This looks great. Thank you, @KaelynJefferson!
Description: This PR adds conditionals to check for entities that exist with the same name, and logs an error when entities are defined with a duplicate name.
Testing Instructions: jest unit tests
Related Issue: Fixes #1469