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

Pre Cache specific data #180

Open
elevin2 opened this issue Jun 10, 2024 · 3 comments
Open

Pre Cache specific data #180

elevin2 opened this issue Jun 10, 2024 · 3 comments

Comments

@elevin2
Copy link

elevin2 commented Jun 10, 2024

Hi,
I'd like to say that this project is great and it really helps with my validations for FHIR resources,
I'm not quite sure if this is already possible, but I want the build a docker that will pre load all required resources on build time (ig, profiles) and will not use terminology server since the docker will be in an offline environment. the docker will enable validation using REST requests
thanks for any help

@grahamegrieve
Copy link
Collaborator

it's really not possible to not use a terminology server - the required resources are very very large indeed. You'd be better to think in terms of also running your own terminology server in the offline environment

@elevin2
Copy link
Author

elevin2 commented Jun 10, 2024

Thanks for the quick response, we are working on having internal terminology server, however it still has time, I saw that in the documentation you can specify -tx n/a but couldn't get it to work.
but even if I have an internal terminology server, is there a way to pre-cache my profiles and ig so it won't try to get them for every request, I want to keep the process running after the initial request, and that all following requests will use the cache from the previous one.

@dotasek
Copy link
Collaborator

dotasek commented Jun 28, 2024

@elevin2 there is a mechanism currently being worked on that does exactly that: https://github.com/hapifhir/org.hl7.fhir.validator-wrapper/tree/do-20240126-baseengine

This runs into some very real limitations depending on the size of the 'preset' CliContext and available memory, so I'm having to fix some issues with session cacheing.

As it functions now, however, if you pay attention to the returned sessionId included in ValidationResponse, you can very much re-use a pre-existing ValidationEngine without having to reload profiles for every validation.

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

No branches or pull requests

3 participants