Package ca.uhn.fhir.jpa.model.entity

Class StorageSettings

java.lang.Object
ca.uhn.fhir.jpa.model.entity.StorageSettings
public class StorageSettings extends Object
This class contains configuration options common to all hapi-fhir-storage implementations. Ultimately it should live in that project

  • Field Details

  • Constructor Details

  • Method Details

    • isAutoCreatePlaceholderReferenceTargets

      public boolean isAutoCreatePlaceholderReferenceTargets()
      When creating or updating a resource: If this property is set to true (default is false), if the resource has a reference to another resource on the local server but that reference does not exist, a placeholder resource will be created.

      In other words, if an observation with subject Patient/FOO is created, but there is no resource called Patient/FOO on the server, this property causes an empty patient with ID "FOO" to be created in order to prevent this operation from failing.

      This property can be useful in cases where replication between two servers is wanted. Note however that references containing purely numeric IDs will not be auto-created as they are never allowed to be client supplied in HAPI FHIR JPA.

      All placeholder resources created in this way have an extension with the URL HapiExtensions.EXT_RESOURCE_PLACEHOLDER and the value "true".

    • setAutoCreatePlaceholderReferenceTargets

      public void setAutoCreatePlaceholderReferenceTargets(boolean theAutoCreatePlaceholderReferenceTargets)
      When creating or updating a resource: If this property is set to true (default is false), if the resource has a reference to another resource on the local server but that reference does not exist, a placeholder resource will be created.

      In other words, if an observation with subject Patient/FOO is created, but there is no resource called Patient/FOO on the server, this property causes an empty patient with ID "FOO" to be created in order to prevent this operation from failing.

      This property can be useful in cases where replication between two servers is wanted. Note however that references containing purely numeric IDs will not be auto-created as they are never allowed to be client supplied in HAPI FHIR JPA.

      All placeholder resources created in this way have an extension with the URL HapiExtensions.EXT_RESOURCE_PLACEHOLDER and the value "true".

    • getBundleBatchPoolSize

      public Integer getBundleBatchPoolSize()
      Get the batch transaction thread pool size.
      Since:
      5.6.0

    • setBundleBatchPoolSize

      public void setBundleBatchPoolSize(Integer theBundleBatchPoolSize)
      Set the batch transaction thread pool size. The default is @see DEFAULT_BUNDLE_BATCH_POOL_SIZE set pool size to 1 for single thread
      Since:
      5.6.0

    • getBundleBatchMaxPoolSize

      public Integer getBundleBatchMaxPoolSize()
      Get the batch transaction thread max pool size. set max pool size to 1 for single thread
      Since:
      5.6.0

    • setBundleBatchMaxPoolSize

      public void setBundleBatchMaxPoolSize(Integer theBundleBatchMaxPoolSize)
      Set the batch transaction thread pool size. The default is @see DEFAULT_BUNDLE_BATCH_MAX_POOL_SIZE
      Since:
      5.6.0

    • getIndexMissingFields

      public StorageSettings.IndexEnabledEnum getIndexMissingFields()
      If set to StorageSettings.IndexEnabledEnum.DISABLED (default is StorageSettings.IndexEnabledEnum.DISABLED) the server will not create search indexes for search parameters with no values in resources.

      Disabling this feature means that the :missing search modifier will not be supported on the server, but also means that storage and indexing (i.e. writes to the database) may be much faster on servers which have lots of search parameters and need to write quickly.

      This feature may be enabled on servers where supporting the use of the :missing parameter is of higher importance than raw write performance

    • setIndexMissingFields

      public void setIndexMissingFields(StorageSettings.IndexEnabledEnum theIndexMissingFields)
      If set to StorageSettings.IndexEnabledEnum.DISABLED (default is StorageSettings.IndexEnabledEnum.DISABLED) the server will not create search indexes for search parameters with no values in resources.

      Disabling this feature means that the :missing search modifier will not be supported on the server, but also means that storage and indexing (i.e. writes to the database) may be much faster on servers which have lots of search parameters and need to write quickly.

      This feature may be enabled on servers where supporting the use of the :missing parameter is of higher importance than raw write performance

      Note that this setting also has an impact on sorting (i.e. using the _sort parameter on searches): If the server is configured to not index missing field.

      The following index may need to be added into the indexed tables such as HFJ_SPIDX_TOKEN to improve the search performance while :missing is enabled. RES_TYPE, SP_NAME, SP_MISSING

    • isIndexStorageOptimized

      public boolean isIndexStorageOptimized()
      If set to true (default is false), the server will not write data to the SP_NAME, RES_TYPE, SP_UPDATED columns for all HFJ_SPIDX tables.

      This feature may be enabled on servers where HFJ_SPIDX tables are expected to have a large amount of data (millions of rows) in order to reduce overall storage size.

      Note that this setting only applies to newly inserted and updated rows in HFJ_SPIDX tables. In order to apply this optimization setting to existing HFJ_SPIDX index rows, $reindex operation should be executed at the instance or server level.

      If this setting is enabled, PartitionSettings.isIncludePartitionInSearchHashes() should be disabled.

      If getIndexMissingFields() is enabled, the following index may need to be added into the HFJ_SPIDX tables to improve the search performance: HASH_IDENTITY, SP_MISSING, RES_ID, PARTITION_ID

      Since:
      7.4.0

    • setIndexStorageOptimized

      public void setIndexStorageOptimized(boolean theIndexStorageOptimized)
      If set to true (default is false), the server will not write data to the SP_NAME, RES_TYPE, SP_UPDATED columns for all HFJ_SPIDX tables.

      This feature may be enabled on servers where HFJ_SPIDX tables are expected to have a large amount of data (millions of rows) in order to reduce overall storage size.

      Note that this setting only applies to newly inserted and updated rows in HFJ_SPIDX tables. In order to apply this optimization setting to existing HFJ_SPIDX index rows, $reindex operation should be executed at the instance or server level.

      If this setting is enabled, PartitionSettings.isIncludePartitionInSearchHashes() should be set to false.

      If getIndexMissingFields() ()} is enabled, the following index may need to be added into the HFJ_SPIDX tables to improve the search performance: HASH_IDENTITY, SP_MISSING, RES_ID, PARTITION_ID

      Since:
      7.4.0

    • isMassIngestionMode

      public boolean isMassIngestionMode()
      If this is enabled (disabled by default), Mass Ingestion Mode is enabled. In this mode, a number of runtime checks are disabled. This mode is designed for rapid backloading of data while the system is not being otherwise used.

      In this mode:

      - Tags/Profiles/Security Labels will not be updated on existing resources that already have them - Resources modification checks will be skipped in favour of a simple hash check - Extra resource ID caching is enabled

      Since:
      5.5.0

    • setMassIngestionMode

      public void setMassIngestionMode(boolean theMassIngestionMode)
      If this is enabled (disabled by default), Mass Ingestion Mode is enabled. In this mode, a number of runtime checks are disabled. This mode is designed for rapid backloading of data while the system is not being otherwise used.

      In this mode:

      - Tags/Profiles/Security Labels will not be updated on existing resources that already have them - Resources modification checks will be skipped in favour of a simple hash check - Extra resource ID caching is enabled

      Since:
      5.5.0

    • getMaximumTransactionBundleSize

      public Integer getMaximumTransactionBundleSize()
      Specifies the maximum number of resources permitted within a single transaction bundle. If a transaction bundle is submitted with more than this number of resources, it will be rejected with a PayloadTooLarge exception.

      The default value is null, which means that there is no limit.

    • setMaximumTransactionBundleSize

      public StorageSettings setMaximumTransactionBundleSize(Integer theMaximumTransactionBundleSize)
      Specifies the maximum number of resources permitted within a single transaction bundle. If a transaction bundle is submitted with more than this number of resources, it will be rejected with a PayloadTooLarge exception.

      The default value is null, which means that there is no limit.

    • isNormalizeTerminologyForBulkExportJobs

      public boolean isNormalizeTerminologyForBulkExportJobs()
      If set to true, attempt to map terminology for bulk export jobs using the logic in ResponseTerminologyTranslationSvc. Default is false.
      Since:
      6.3.0

    • setNormalizeTerminologyForBulkExportJobs

      public void setNormalizeTerminologyForBulkExportJobs(boolean theNormalizeTerminologyForBulkExportJobs)
      If set to true, attempt to map terminology for bulk export jobs using the logic in ResponseTerminologyTranslationSvc. Default is false.
      Since:
      6.3.0

    • getSequenceValueMassagerClass

      public Class<? extends ISequenceValueMassager> getSequenceValueMassagerClass()
      This is an internal API and may change or disappear without notice
      Since:
      6.2.0

    • setSequenceValueMassagerClass

      public void setSequenceValueMassagerClass(Class<? extends ISequenceValueMassager> theSequenceValueMassagerClass)
      This is an internal API and may change or disappear without notice
      Since:
      6.2.0

    • isIndexIdentifierOfType

      public boolean isIndexIdentifierOfType()
      If set to true (default is false) the :of-type modifier on token search parameters for identifiers will be supported. Enabling this causes additional indexing overhead (although very minor) so it is disabled unless it is actually needed.
      Since:
      5.7.0

    • setIndexIdentifierOfType

      public void setIndexIdentifierOfType(boolean theIndexIdentifierOfType)
      If set to true (default is false) the :of-type modifier on token search parameters for identifiers will be supported. Enabling this causes additional indexing overhead (although very minor) so it is disabled unless it is actually needed.
      Since:
      5.7.0

    • isDefaultSearchParamsCanBeOverridden

      public boolean isDefaultSearchParamsCanBeOverridden()
      If set to true the default search params (i.e. the search parameters that are defined by the FHIR specification itself) may be overridden by uploading search parameters to the server with the same code as the built-in search parameter.

      This can be useful if you want to be able to disable or alter the behaviour of the default search parameters.

      The default value for this setting is true

    • setDefaultSearchParamsCanBeOverridden

      public void setDefaultSearchParamsCanBeOverridden(boolean theDefaultSearchParamsCanBeOverridden)
      If set to true the default search params (i.e. the search parameters that are defined by the FHIR specification itself) may be overridden by uploading search parameters to the server with the same code as the built-in search parameter.

      This can be useful if you want to be able to disable or alter the behaviour of the default search parameters.

      The default value for this setting is true

    • isAllowContainsSearches

      public boolean isAllowContainsSearches()
      If enabled, the server will support the use of :contains searches, which are helpful but can have adverse effects on performance.

      Default is false (Note that prior to HAPI FHIR 3.5.0 the default was true)

      Note: If you change this value after data already has already been stored in the database, you must for a reindexing of all data in the database or resources may not be searchable.

    • setAllowContainsSearches

      public void setAllowContainsSearches(boolean theAllowContainsSearches)
      If enabled, the server will support the use of :contains searches, which are helpful but can have adverse effects on performance.

      Default is false (Note that prior to HAPI FHIR 3.5.0 the default was true)

      Note: If you change this value after data already has already been stored in the database, you must for a reindexing of all data in the database or resources may not be searchable.

    • isAllowMdmExpansion

      public boolean isAllowMdmExpansion()
      If enabled, the server will support the use of :mdm search parameter qualifier on Reference Search Parameters. This Parameter Qualifier is HAPI-specific, and not defined anywhere in the FHIR specification. Using this qualifier will result in an MDM expansion being done on the reference, which will expand the search scope. For example, if Patient/1 is MDM-matched to Patient/2 and you execute the search: Observation?subject:mdm=Patient/1 , you will receive observations for both Patient/1 and Patient/2.

      Default is false

      Since:
      5.4.0

    • setAllowMdmExpansion

      public void setAllowMdmExpansion(boolean theAllowMdmExpansion)
      If enabled, the server will support the use of :mdm search parameter qualifier on Reference Search Parameters. This Parameter Qualifier is HAPI-specific, and not defined anywhere in the FHIR specification. Using this qualifier will result in an MDM expansion being done on the reference, which will expand the search scope. For example, if Patient/1 is MDM-matched to Patient/2 and you execute the search: Observation?subject:mdm=Patient/1 , you will receive observations for both Patient/1 and Patient/2.

      Default is false

      Since:
      5.4.0

    • isAllowExternalReferences

      public boolean isAllowExternalReferences()
      If set to true (default is false) the server will allow resources to have references to external servers. For example if this server is running at http://example.com/fhir and this setting is set to true the server will allow a Patient resource to be saved with a Patient.organization value of http://foo.com/Organization/1.

      Under the default behaviour if this value has not been changed, the above resource would be rejected by the server because it requires all references to be resolvable on the local server.

      Note that external references will be indexed by the server and may be searched (e.g. Patient:organization), but chained searches (e.g. Patient:organization.name) will not work across these references.

      It is recommended to also set setTreatBaseUrlsAsLocal(Set) if this value is set to true

      See Also:

    • setAllowExternalReferences

      public void setAllowExternalReferences(boolean theAllowExternalReferences)
      If set to true (default is false) the server will allow resources to have references to external servers. For example if this server is running at http://example.com/fhir and this setting is set to true the server will allow a Patient resource to be saved with a Patient.organization value of http://foo.com/Organization/1.

      Under the default behaviour if this value has not been changed, the above resource would be rejected by the server because it requires all references to be resolvable on the local server.

      Note that external references will be indexed by the server and may be searched (e.g. Patient:organization), but chained searches (e.g. Patient:organization.name) will not work across these references.

      It is recommended to also set setTreatBaseUrlsAsLocal(Set) if this value is set to true

      See Also:

    • getTreatBaseUrlsAsLocal

      public Set<String> getTreatBaseUrlsAsLocal()
      This setting may be used to advise the server that any references found in resources that have any of the base URLs given here will be replaced with simple local references.

      For example, if the set contains the value http://example.com/base/ and a resource is submitted to the server that contains a reference to http://example.com/base/Patient/1, the server will automatically convert this reference to Patient/1

      Note that this property has different behaviour from getTreatReferencesAsLogical()

      See Also:

    • setTreatBaseUrlsAsLocal

      public void setTreatBaseUrlsAsLocal(Set<String> theTreatBaseUrlsAsLocal)
      This setting may be used to advise the server that any references found in resources that have any of the base URLs given here will be replaced with simple local references.

      For example, if the set contains the value http://example.com/base/ and a resource is submitted to the server that contains a reference to http://example.com/base/Patient/1, the server will automatically convert this reference to Patient/1

      Parameters:
      theTreatBaseUrlsAsLocal - The set of base URLs. May be null, which means no references will be treated as external

    • addTreatReferencesAsLogical

      public void addTreatReferencesAsLogical(String theTreatReferencesAsLogical)
      Add a value to the logical references list.
      See Also:

    • getTreatReferencesAsLogical

      public Set<String> getTreatReferencesAsLogical()
      This setting may be used to advise the server that any references found in resources that have any of the base URLs given here will be treated as logical references instead of being treated as real references.

      A logical reference is a reference which is treated as an identifier, and does not neccesarily resolve. See references for a description of logical references. For example, the valueset valueset-quantity-comparator is a logical reference.

      Values for this field may take either of the following forms:

      • http://example.com/some-url (will be matched exactly)
      • http://example.com/some-base* (will match anything beginning with the part before the *)
      See Also:

    • setTreatReferencesAsLogical

      public StorageSettings setTreatReferencesAsLogical(Set<String> theTreatReferencesAsLogical)
      This setting may be used to advise the server that any references found in resources that have any of the base URLs given here will be treated as logical references instead of being treated as real references.

      A logical reference is a reference which is treated as an identifier, and does not neccesarily resolve. See references for a description of logical references. For example, the valueset valueset-quantity-comparator is a logical reference.

      Values for this field may take either of the following forms:

      • http://example.com/some-url (will be matched exactly)
      • http://example.com/some-base* (will match anything beginning with the part before the *)
      See Also:

    • getUseOrdinalDatesForDayPrecisionSearches

      public boolean getUseOrdinalDatesForDayPrecisionSearches()

      Should searches use the integer field SP_VALUE_LOW_DATE_ORDINAL and SP_VALUE_HIGH_DATE_ORDINAL in ResourceIndexedSearchParamDate when resolving searches where all predicates are using precision of TemporalPrecisionEnum.DAY.

      For example, if enabled, the search of Observation?date=2020-02-25 will cause the date to be collapsed down to an integer representing the ordinal date 20200225. It would then be compared against ResourceIndexedSearchParamDate.getValueLowDateOrdinal() and ResourceIndexedSearchParamDate.getValueHighDateOrdinal()

      Default is true beginning in HAPI FHIR 5.0.0

      Since:
      5.0.0

    • setUseOrdinalDatesForDayPrecisionSearches

      public void setUseOrdinalDatesForDayPrecisionSearches(boolean theUseOrdinalDates)

      Should searches use the integer field SP_VALUE_LOW_DATE_ORDINAL and SP_VALUE_HIGH_DATE_ORDINAL in ResourceIndexedSearchParamDate when resolving searches where all predicates are using precision of TemporalPrecisionEnum.DAY.

      For example, if enabled, the search of Observation?date=2020-02-25 will cause the date to be collapsed down to an ordinal 20200225. It would then be compared against ResourceIndexedSearchParamDate.getValueLowDateOrdinal() and ResourceIndexedSearchParamDate.getValueHighDateOrdinal()

      Default is true beginning in HAPI FHIR 5.0.0

      Since:
      5.0.0

    • isSuppressStringIndexingInTokens

      public boolean isSuppressStringIndexingInTokens()
      If set to true (default is false), when indexing SearchParameter values for token SearchParameter, the string component to support the :text modifier will be disabled. This means that the following fields will not be indexed for tokens:
      • CodeableConcept.text
      • Coding.display
      • Identifier.use.text
      Since:
      5.0.0

    • setSuppressStringIndexingInTokens

      public void setSuppressStringIndexingInTokens(boolean theSuppressStringIndexingInTokens)
      If set to true (default is false), when indexing SearchParameter values for token SearchParameter, the string component to support the :text modifier will be disabled. This means that the following fields will not be indexed for tokens:
      • CodeableConcept.text
      • Coding.display
      • Identifier.use.text
      Since:
      5.0.0

    • getPeriodIndexStartOfTime

      public org.hl7.fhir.instance.model.api.IPrimitiveType<Date> getPeriodIndexStartOfTime()
      When indexing a Period (e.g. Encounter.period) where the period has an upper bound but not a lower bound, a canned "start of time" value can be used as the lower bound in order to allow range searches to correctly identify all values in the range.

      The default value for this is DEFAULT_PERIOD_INDEX_START_OF_TIME which is probably good enough for almost any application, but this can be changed if needed.

      Note the following database documented limitations:

      • JDBC Timestamp Datatype Low Value -4713 and High Value 9999
      • MySQL 8: the range for DATETIME values is '1000-01-01 00:00:00.000000' to '9999-12-31 23:59:59.999999`
      • Postgresql 12: Timestamp [without time zone] Low Value 4713 BC and High Value 294276 AD
      • Oracle: Timestamp Low Value 4712 BC and High Value 9999 CE
      • H2: datetime2 Low Value -4713 and High Value 9999

      Since:
      5.1.0
      See Also:

    • setPeriodIndexStartOfTime

      public void setPeriodIndexStartOfTime(org.hl7.fhir.instance.model.api.IPrimitiveType<Date> thePeriodIndexStartOfTime)
      When indexing a Period (e.g. Encounter.period) where the period has an upper bound but not a lower bound, a canned "start of time" value can be used as the lower bound in order to allow range searches to correctly identify all values in the range.

      The default value for this is DEFAULT_PERIOD_INDEX_START_OF_TIME which is probably good enough for almost any application, but this can be changed if needed.

      Note the following database documented limitations:

      • JDBC Timestamp Datatype Low Value -4713 and High Value 9999
      • MySQL 8: the range for DATETIME values is '1000-01-01 00:00:00.000000' to '9999-12-31 23:59:59.999999`
      • Postgresql 12: Timestamp [without time zone] Low Value 4713 BC and High Value 294276 AD
      • Oracle: Timestamp Low Value 4712 BC and High Value 9999 CE
      • H2: datetime2 Low Value -4713 and High Value 9999

      Since:
      5.1.0
      See Also:

    • getPeriodIndexEndOfTime

      public org.hl7.fhir.instance.model.api.IPrimitiveType<Date> getPeriodIndexEndOfTime()
      When indexing a Period (e.g. Encounter.period) where the period has a lower bound but not an upper bound, a canned "end of time" value can be used as the upper bound in order to allow range searches to correctly identify all values in the range.

      The default value for this is DEFAULT_PERIOD_INDEX_START_OF_TIME which is probably good enough for almost any application, but this can be changed if needed.

      Note the following database documented limitations:

      • JDBC Timestamp Datatype Low Value -4713 and High Value 9999
      • MySQL 8: the range for DATETIME values is '1000-01-01 00:00:00.000000' to '9999-12-31 23:59:59.999999`
      • Postgresql 12: Timestamp [without time zone] Low Value 4713 BC and High Value 294276 AD
      • Oracle: Timestamp Low Value 4712 BC and High Value 9999 CE
      • H2: datetime2 Low Value -4713 and High Value 9999

      Since:
      5.1.0
      See Also:

    • setPeriodIndexEndOfTime

      public void setPeriodIndexEndOfTime(org.hl7.fhir.instance.model.api.IPrimitiveType<Date> thePeriodIndexEndOfTime)
      When indexing a Period (e.g. Encounter.period) where the period has an upper bound but not a lower bound, a canned "start of time" value can be used as the lower bound in order to allow range searches to correctly identify all values in the range.

      The default value for this is DEFAULT_PERIOD_INDEX_START_OF_TIME which is probably good enough for almost any application, but this can be changed if needed.

      Note the following database documented limitations:

      • JDBC Timestamp Datatype Low Value -4713 and High Value 9999
      • MySQL 8: the range for DATETIME values is '1000-01-01 00:00:00.000000' to '9999-12-31 23:59:59.999999`
      • Postgresql 12: Timestamp [without time zone] Low Value 4713 BC and High Value 294276 AD
      • Oracle: Timestamp Low Value 4712 BC and High Value 9999 CE
      • H2: datetime2 Low Value -4713 and High Value 9999

      Since:
      5.1.0
      See Also:

    • getNormalizedQuantitySearchLevel

      public NormalizedQuantitySearchLevel getNormalizedQuantitySearchLevel()
      Toggles whether Quantity searches support value normalization when using valid UCUM coded values.

      The default value is NormalizedQuantitySearchLevel.NORMALIZED_QUANTITY_SEARCH_NOT_SUPPORTED which is current behavior.

      Here is the UCUM service support level

      Since:
      5.3.0

    • setNormalizedQuantitySearchLevel

      public void setNormalizedQuantitySearchLevel(NormalizedQuantitySearchLevel theNormalizedQuantitySearchLevel)
      Toggles whether Quantity searches support value normalization when using valid UCUM coded values.

      The default value is NormalizedQuantitySearchLevel.NORMALIZED_QUANTITY_SEARCH_NOT_SUPPORTED which is current behavior.

      Here is the UCUM service support level

      Since:
      5.3.0

    • getAutoVersionReferenceAtPaths

      public Set<String> getAutoVersionReferenceAtPaths()
      When set with resource paths (e.g. "Observation.subject"), any references found at the given paths will automatically have versions appended. The version used will be the current version of the given resource.
      Since:
      5.3.0

    • setAutoVersionReferenceAtPaths

      public void setAutoVersionReferenceAtPaths(String... thePaths)
      When set with resource paths (e.g. "Observation.subject"), any references found at the given paths will automatically have versions appended. The version used will be the current version of the given resource.

      Versions will only be added if the reference does not already have a version, so any versioned references supplied by the client will take precedence over the automatic current version.

      Note that for this setting to be useful, the ParserOptions DontStripVersionsFromReferencesAtPaths option must also be set.

      Parameters:
      thePaths - A collection of reference paths for which the versions will be appended automatically when serializing, e.g. "Patient.managingOrganization" or "AuditEvent.object.reference". Note that only resource name and field names with dots separating is allowed here (no repetition indicators, FluentPath expressions, etc.)
      Since:
      5.3.0

    • setAutoVersionReferenceAtPaths

      public void setAutoVersionReferenceAtPaths(Set<String> thePaths)
      When set with resource paths (e.g. "Observation.subject"), any references found at the given paths will automatically have versions appended. The version used will be the current version of the given resource.

      Versions will only be added if the reference does not already have a version, so any versioned references supplied by the client will take precedence over the automatic current version.

      Note that for this setting to be useful, the ParserOptions DontStripVersionsFromReferencesAtPaths option must also be set

      Parameters:
      thePaths - A collection of reference paths for which the versions will be appended automatically when serializing, e.g. "Patient.managingOrganization" or "AuditEvent.object.reference". Note that only resource name and field names with dots separating is allowed here (no repetition indicators, FluentPath expressions, etc.)
      Since:
      5.3.0

    • getAutoVersionReferenceAtPathsByResourceType

      public Set<String> getAutoVersionReferenceAtPathsByResourceType(String theResourceType)
      Returns a sub-collection of getAutoVersionReferenceAtPaths() containing only paths for the given resource type.
      Since:
      5.3.0

    • isRespectVersionsForSearchIncludes

      public boolean isRespectVersionsForSearchIncludes()
      Should searches with _include respect versioned references, and pull the specific requested version. This may have performance impacts on heavily loaded systems.
      Since:
      5.3.0

    • setRespectVersionsForSearchIncludes

      public void setRespectVersionsForSearchIncludes(boolean theRespectVersionsForSearchIncludes)
      Should searches with _include respect versioned references, and pull the specific requested version. This may have performance impacts on heavily loaded systems.
      Since:
      5.3.0

    • isIndexOnUpliftedRefchains

      public boolean isIndexOnUpliftedRefchains()
      If enabled, "Uplifted Refchains" will be enabled. This feature causes HAPI FHIR to generate indexes for stored resources that include the current value of the target of a chained reference, such as "Encounter?subject.name".
      Since:
      6.6.0

    • setIndexOnUpliftedRefchains

      public void setIndexOnUpliftedRefchains(boolean theIndexOnUpliftedRefchains)
      If enabled, "Uplifted Refchains" will be enabled. This feature causes HAPI FHIR to generate indexes for stored resources that include the current value of the target of a chained reference, such as "Encounter?subject.name".
      Since:
      6.6.0

    • isIndexOnContainedResources

      public boolean isIndexOnContainedResources()
      Should indexing and searching on contained resources be enabled on this server. This may have performance impacts, and should be enabled only if it is needed. Default is false.
      Since:
      5.4.0

    • setIndexOnContainedResources

      public void setIndexOnContainedResources(boolean theIndexOnContainedResources)
      Should indexing and searching on contained resources be enabled on this server. This may have performance impacts, and should be enabled only if it is needed. Default is false.
      Since:
      5.4.0

    • isIndexOnContainedResourcesRecursively

      public boolean isIndexOnContainedResourcesRecursively()
      Should recursive indexing and searching on contained resources be enabled on this server. This may have performance impacts, and should be enabled only if it is needed. Default is false.
      Since:
      5.6.0

    • setIndexOnContainedResourcesRecursively

      public void setIndexOnContainedResourcesRecursively(boolean theIndexOnContainedResourcesRecursively)
      Should recursive indexing and searching on contained resources be enabled on this server. This may have performance impacts, and should be enabled only if it is needed. Default is false.
      Since:
      5.6.0

    • isAutoSupportDefaultSearchParams

      public boolean isAutoSupportDefaultSearchParams()
      If this is disabled by setting this to false (default is true), the server will not automatically implement and support search parameters that are not explcitly created in the repository.

      Disabling this can have a dramatic improvement on performance (especially write performance) in servers that only need to support a small number of search parameters, or no search parameters at all. Disabling this obviously reduces the options for searching however.

      Since:
      5.7.0

    • setAutoSupportDefaultSearchParams

      public void setAutoSupportDefaultSearchParams(boolean theAutoSupportDefaultSearchParams)
      If this is disabled by setting this to false (default is true), the server will not automatically implement and support search parameters that are not explcitly created in the repository.

      Disabling this can have a dramatic improvement on performance (especially write performance) in servers that only need to support a small number of search parameters, or no search parameters at all. Disabling this obviously reduces the options for searching however.

      Since:
      5.7.0

    • isLanguageSearchParameterEnabled

      public boolean isLanguageSearchParameterEnabled()
      Returns:
      Should the _lamguage SearchParameter be supported on this server? Defaults to false.
      Since:
      7.0.0

    • setLanguageSearchParameterEnabled

      public void setLanguageSearchParameterEnabled(boolean theLanguageSearchParameterEnabled)
      Should the _lamguage SearchParameter be supported on this server? Defaults to false.
      Since:
      7.0.0

    • isValidateResourceStatusForPackageUpload

      public boolean isValidateResourceStatusForPackageUpload()
      Returns:
      true if the filter is enabled for resources installed via package installer, false otherwise
      Since:
      7.0.0

    • setValidateResourceStatusForPackageUpload

      public void setValidateResourceStatusForPackageUpload(boolean theValidateResourceStatusForPackageUpload)
      Should resources being installed via package installer be filtered.
      Since:
      7.0.0