You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Or alternately support providing the cache to the settings object so that you don't need to maintain an essentially static validator.
My use case is that I have transient profiles that I wish to validate in the service and not retain the extra compiled schemas for the transient profiles.
The CachedResolver has access to clear and invalidate a URL - these are specifically what I would like to be able to do.
The way I used this in the old validator was to provide the following as myroutines source
varinMemResolver= ...;// an in memory resolver that's backed by a simple Dictionary that is populated in the operationvar_dirSource=newDirectorySource(Directory, ...);varcacheResolver=newCachedResolver(newMultiResolver(_dbResolver,_dirSource,ZipSource.CreateValidationSource()));source=newMultiResolver(inMemResolver,cachedResolver);
Interestingly you copy over the cache in the constructor, even if it already had one too - which would have been a technique to retain the settings, but not the cache - which I'd argue was tied to the resolver...
I assume there was a reason not to put the cache content into an annotation in the SD from the resolver.
The text was updated successfully, but these errors were encountered:
Or alternately support providing the cache to the settings object so that you don't need to maintain an essentially static validator.
My use case is that I have transient profiles that I wish to validate in the service and not retain the extra compiled schemas for the transient profiles.
The CachedResolver has access to clear and invalidate a URL - these are specifically what I would like to be able to do.
The way I used this in the old validator was to provide the following as myroutines source
Interestingly you copy over the cache in the constructor, even if it already had one too - which would have been a technique to retain the settings, but not the cache - which I'd argue was tied to the resolver...
I assume there was a reason not to put the cache content into an annotation in the SD from the resolver.
The text was updated successfully, but these errors were encountered: