Skip to content

Using 2.0, still unable to use Add command on schemas #198

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

Closed
CraigRegester opened this issue May 3, 2022 · 4 comments · Fixed by #199
Closed

Using 2.0, still unable to use Add command on schemas #198

CraigRegester opened this issue May 3, 2022 · 4 comments · Fixed by #199
Assignees
Labels
customer Based on customer feedback (as opposed to something identified by developers)

Comments

@CraigRegester
Copy link
Contributor

Using latest release and a package mapping that looks like this:

image

I go to Interoperability->HL7 Schemas, pick a custom schema we have and using the Source Control button (up next to Delete), I select 'Add' from the menu.

This is the error that immediately pops up:
image

If I look in the Source Control output, however, it seems to have worked....
image

image

Maybe related to #191? Since I have multiple file types pointed to the same output folder? Not sure...

@CraigRegester
Copy link
Contributor Author

As a related aside, might be prudent to setup the default output folders for the File Type mappings to match what has been used for quite some time now in VS Code ObjectScript extension... e.g., /src/cls, /src/rtn, /src/inc, /src/oth

Makes it a lot easier for my more advanced developers to use the best of both worlds.

@CraigRegester
Copy link
Contributor Author

Ok it partially works - it adds the global entry for the TSH but not for the item itself. And the file itself, in the git repository, is in a status of 'untracked'

image
(different file but same premise - I was trying a few things to try and ensure I wasn't causing the issue somehow.)

@isc-svelury
Copy link
Contributor

This is happening because LUT and HL7 files have the same export path. It would have also happened if the LUT files had an export folder that was an ancestor folder of the HL7 files. It is a consequence of the way we match mappings currently. The only way I can think of to fix this behavior would be to check if the file extension matches the one in the mapping.

@isc-tleavitt would that be acceptable? We discuss a related issue in #176 and conclude that exporting "as-is" is the right thing to do, so ideally we shouldn't have files exported with a different extension than their own.

@isc-tleavitt
Copy link
Collaborator

@isc-svelury that would be acceptable as a fallback option.

@isc-tleavitt isc-tleavitt added the customer Based on customer feedback (as opposed to something identified by developers) label May 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
customer Based on customer feedback (as opposed to something identified by developers)
Projects
None yet
3 participants