Annotation Interface QueryOptions
Annotation to set additional query options for custom AQL (ArangoDB Query
Language) queries defined on repository methods.
- Author:
- Mark Vollmary
-
Optional Element Summary
Optional ElementsModifier and TypeOptional ElementDescriptionboolean
Set to true allows reading from followers in an active-failover setup.boolean
Set this option to true to make it possible to retry fetching the latest batch from a cursor.int
Maximum number of result documents to be transferred from the server to the client in one roundtrip.boolean
Flag to determine whether the AQL query cache shall be used.boolean
Indicates whether the number of documents in the result set should be returned in the "count" attribute of the result.boolean
If set to true and the query contains a LIMIT clause, then the result will have an extra attribute with the sub-attributes stats and fullCount, { ... , "extra": { "stats": { "fullCount": 123 } } }.int
Limits the maximum number of plans that are created by the AQL query optimizer.long
The maximum number of memory (measured in bytes) that the query is allowed to use.boolean
If set to true, then the additional query profiling information will be returned in the sub-attribute profile of the extra return attribute if the query result is not served from the query cache.String[]
A list of to-be-included or to-be-excluded optimizer rules can be put into this attribute, telling the optimizer to include or exclude specific rules.boolean
Specify true and the query will be executed in a streaming fashion.int
The time-to-live for the cursor (in seconds).
-
Element Details
-
batchSize
int batchSizeMaximum number of result documents to be transferred from the server to the client in one roundtrip. If this attribute is not set, a server-controlled default value will be used. A batchSize value of 0 is disallowed.- Default:
- -1
-
cache
boolean cacheFlag to determine whether the AQL query cache shall be used. If set to false, then any query cache lookup will be skipped for the query. If set to true, it will lead to the query cache being checked for the query if the query cache mode is either on or demand.- Default:
- false
-
count
boolean countIndicates whether the number of documents in the result set should be returned in the "count" attribute of the result. Calculating the "count" attribute might have a performance impact for some queries in the future so this option is turned off by default, and "count" is only returned when requested.- Default:
- false
-
fullCount
boolean fullCountIf set to true and the query contains a LIMIT clause, then the result will have an extra attribute with the sub-attributes stats and fullCount, { ... , "extra": { "stats": { "fullCount": 123 } } }. The fullCount attribute will contain the number of documents in the result before the last LIMIT in the query was applied. It can be used to count the number of documents that match certain filter criteria, but only return a subset of them, in one go. It is thus similar to MySQL's SQL_CALC_FOUND_ROWS hint. Note that setting the option will disable a few LIMIT optimizations and may lead to more documents being processed, and thus make queries run longer. Note that the fullCount attribute will only be present in the result if the query has a LIMIT clause and the LIMIT clause is actually used in the query.- Default:
- false
-
maxPlans
int maxPlansLimits the maximum number of plans that are created by the AQL query optimizer.- Default:
- -1
-
profile
boolean profileIf set to true, then the additional query profiling information will be returned in the sub-attribute profile of the extra return attribute if the query result is not served from the query cache.- Default:
- false
-
rules
String[] rulesA list of to-be-included or to-be-excluded optimizer rules can be put into this attribute, telling the optimizer to include or exclude specific rules. To disable a rule, prefix its name with a -, to enable a rule, prefix it with a +. There is also a pseudo-rule all, which will match all optimizer rules- Default:
- {}
-
ttl
int ttlThe time-to-live for the cursor (in seconds). The cursor will be removed on the server automatically after the specified amount of time. This is useful to ensure garbage collection of cursors that are not fully fetched by clients. If not set, a server-defined value will be used.- Default:
- -1
-
stream
boolean streamSpecify true and the query will be executed in a streaming fashion. The query result is not stored on the server, but calculated on the fly. Beware: long-running queries will need to hold the collection locks for as long as the query cursor exists. When set to false a query will be executed right away in its entirety. In that case query results are either returned right away (if the resultset is small enough), or stored on the arangod instance and accessible via the cursor API (with respect to the ttl). It is advisable to only use this option on short-running queries or without exclusive locks (write-locks on MMFiles). Please note that the query options cache, count and fullCount will not work on streaming queries. Additionally query statistics, warnings and profiling data will only be available after the query is finished. The default value is false- Since:
- ArangoDB 3.4.0
- Default:
- false
-
memoryLimit
long memoryLimitThe maximum number of memory (measured in bytes) that the query is allowed to use. If set, then the query will fail with error "resource limit exceeded" in case it allocates too much memory. A value of 0 indicates that there is no memory limit.- Since:
- ArangoDB 3.1.0
- Default:
- -1L
-
allowDirtyRead
boolean allowDirtyReadSet to true allows reading from followers in an active-failover setup.- Since:
- ArangoDB 3.4.0
- Default:
- false
-
allowRetry
boolean allowRetrySet this option to true to make it possible to retry fetching the latest batch from a cursor. This makes possible to safely retry invokingArangoCursor.next()
in case of I/O exceptions (which are actually thrown asArangoDBException
with causeIOException
) If set to false (default), then it is not safe to retry invokingArangoCursor.next()
in case of I/O exceptions, since the request to fetch the next batch is not idempotent (i.e. the cursor may advance multiple times on the server). Note: once you successfully received the last batch, you should callCloseable.close()
so that the server does not unnecessary keep the batch until the cursor times out (AqlQueryOptions.ttl(Integer)
).- Default:
- false
-