Pre Cache specific data

[elevin2]

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]

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]

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]

@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.

[dotasek]

@elevin2 To follow up, the validator website has now been effectively using the preloaded ValidationEngine functionality in the above PR for about ten days now.

I would like close this issue and divide it into two distinct issues:

1. Using a custom terminology server. This would contain replication steps for what you are trying to accomplish.
2. Configuration for pre-loaded ValidationEngines. At present time these are hard-coded, but I think it wouldn't be much work to transformed this into a configuration JSON.