Interface IDatabaseSettings
Default values are:
-
Nested Class Summary
Nested ClassesModifier and TypeInterfaceDescriptionstatic enumDefines the behavior for Get-by-key queries.static enumDefines when clustering fields should be used. -
Field Summary
FieldsModifier and TypeFieldDescriptionstatic final booleanstatic final Durationstatic final IDatabaseSettings.GetByKeyBehaviorstatic final intstatic final IDatabaseSettings.UseClusteringFields -
Method Summary
Modifier and TypeMethodDescriptionbooleanIndicates whether queries on multi-rows vectors should be factorized when possible.Timeout (in seconds) which can be set on a query running on the external database during the feeding.While Get-by-key queries performed on the datastore are very fast, they can take a long time on external databases, solely due to the networking time.intA query clustered by too many fields or by fields with a high cardinality can be divided in lots of sub queries.Returns whether clustering fields should be used for all queries or only forfeeding queries.
-
Field Details
-
DEFAULT_MAX_SUB_QUERIES_ALLOWED_IN_MULTI_STEP_QUERY
static final int DEFAULT_MAX_SUB_QUERIES_ALLOWED_IN_MULTI_STEP_QUERY- See Also:
-
DEFAULT_GET_BY_KEY_QUERY_BEHAVIOR
-
DEFAULT_USE_CLUSTERING_FIELDS
-
DEFAULT_FEEDING_QUERY_TIMEOUT_LIMIT
-
DEFAULT_FACTORIZE_MULTI_ROW_VECTOR_AGGREGATION
static final boolean DEFAULT_FACTORIZE_MULTI_ROW_VECTOR_AGGREGATION- See Also:
-
-
Method Details
-
maxSubQueriesAllowedInMultiStepQuery
int maxSubQueriesAllowedInMultiStepQuery()A query clustered by too many fields or by fields with a high cardinality can be divided in lots of sub queries. To avoid creating too many queries on the external database, a limit is set on the number of those sub queries. This property sets the limit.It is recommended to be conservative when increasing the limit. See documentation for more details.
Defaults to 500.
-
getByKeyBehavior
IDatabaseSettings.GetByKeyBehavior getByKeyBehavior()While Get-by-key queries performed on the datastore are very fast, they can take a long time on external databases, solely due to the networking time. When performing a Get-by-key query through DirectQuery, the possible behaviors are denying, warning, or allowing the query to run.Defaults to
DEFAULT_GET_BY_KEY_QUERY_BEHAVIOR. -
useClusteringFields
IDatabaseSettings.UseClusteringFields useClusteringFields()Returns whether clustering fields should be used for all queries or only forfeeding queries.Defaults to
DEFAULT_USE_CLUSTERING_FIELDS. -
feedingQueryTimeout
Duration feedingQueryTimeout()Timeout (in seconds) which can be set on a query running on the external database during the feeding.Feeding queries are the ones run during the initial loading to feed the aggregate providers and hierarchies, and also during the refresh operations.
It defaults to 1 hour and cannot be less than a second.
This limit is only for external databases and does not impact queries on datastore.
Warning: increasing this value might result in longer queries and higher costs.
-
factorizeMultiRowVectorAggregation
boolean factorizeMultiRowVectorAggregation()Indicates whether queries on multi-rows vectors should be factorized when possible.Queries on multi-rows vectors can sometimes be factorized to reduce the size of intermediate results. This optimization works well when there are many-to-one relationships between the base table and the multi-rows vector table. In this case, summing across the base table without factorization would lead to the computation: vn + vn + vn. With factorization, the computation becomes: 3 * vn, which is more efficient. However, for one-to-one relationships, factorization does not provide any benefit and even does a useless multiplication by 1.
Defaults to
DEFAULT_FACTORIZE_MULTI_ROW_VECTOR_AGGREGATION.
-