Package org.eclipse.rdf4j.query

Interface Query

All Superinterfaces:
Operation
All Known Subinterfaces:
BooleanQuery, GraphQuery, TupleQuery
All Known Implementing Classes:
AbstractHTTPQuery, AbstractParserQuery, AbstractParserQuery, AbstractQuery, DelegatingGraphQuery, DelegatingTupleQuery, FedXBooleanQuery, FedXGraphQuery, FedXTupleQuery, HTTPBooleanQuery, HTTPGraphQuery, HTTPTupleQuery, LoggingGraphQuery, LoggingTupleQuery, ResultCachingGraphQuery, ResultCachingTupleQuery, SailBooleanQuery, SailGraphQuery, SailQuery, SailTupleQuery, SPARQLBooleanQuery, SPARQLGraphQuery, SPARQLTupleQuery
public interface Query extends Operation
A query on a repository that can be formulated in one of the supported query languages (for example SPARQL). It allows one to predefine bindings in the query to be able to reuse the same query with different bindings.
Author:
Arjohn Kampman, jeen

  • Method Details

    • setMaxQueryTime

      @Deprecated(since="2.0") void setMaxQueryTime(int maxQueryTime)
      Deprecated.
      Use Operation.setMaxExecutionTime(int) instead.
      Specifies the maximum time that a query is allowed to run. The query will be interrupted when it exceeds the time limit. Any consecutive requests to fetch query results will result in QueryInterruptedExceptions.
      Parameters:
      maxQueryTime - The maximum query time, measured in seconds. A negative or zero value indicates an unlimited query time (which is the default).

    • getMaxQueryTime

      @Deprecated(since="2.0") int getMaxQueryTime()
      Deprecated.
      Use Operation.getMaxExecutionTime() instead.
      Returns the maximum query evaluation time.
      Returns:
      The maximum query evaluation time, measured in seconds.
      See Also:

    • explain

      @Experimental default Explanation explain(Explanation.Level level)

      Explain how the query will be (or has been) executed/evaluated by returning an explanation of the query plan.

      This method is useful for understanding why a particular query is slow. The most useful level is Executed, but this takes as long as it takes to execute/evaluate the query.

      When timing a query you should keep in mind that the query performance will vary based on how much the JIT compiler has compiled the code (C1 vs C2) and based on what is or isn't cached in memory. If Timed explanations are considerably slower than Executed explanations the overhead with timing the query may be large on your system and should not be trusted.

      WARNING: This method is experimental and is subject to change or removal without warning. Same goes for the returned explanation. There is currently only partial support for this method in RDF4J and and UnsupportedOperationException where support is lacking.

      Parameters:
      level - The explanation level that should be used to create the explanation. Choose between: Unoptimized (as parsed without optimizations) , Optimized (as is actually going to be used), Executed (as was executed/evaluated, including some real performance metrics), Timed (as was executed/evaluated including all real performance metrics). Executed and Timed level can potentially be slow.
      Returns:
      The explanation that we generated, which can be viewed in a human readable format with toString(), as JSON or as a simplified query plan object structure.