Search Service API

Showing results for 
Search instead for 
Did you mean: 

Search Service API

0 0 3,307

Obsolete Pages{{Obsolete}}

The official documentation is at:



public ResultSet query(StoreRef[] stores, String language, String query)
public ResultSet query(StoreRef[] stores, String language, String query, String[] queryParameters)

These functions search:

  • the index associated with a workspace (defined by StoreRef[] stores)
  • using the given query (defined as String query)
  • within the query type (defined as String language). Example query types are 'Lucene', 'Extended Lucene', 'JCR-170-XPath', 'JCR-170-SQL'. 
  • The query returns a read only set of results as a java.lang.Iterable.ResultSet.
public ResultSet query(StoreRef[] stores, String language, String query, String[]queryOptions)
public ResultSet query(StoreRef[] stores, String language, String query, String[]queryOptions, String[] queryParameters)

As above but provides an array of query options (defined by String[] queryOptions).  While the XPath and Lucene style queries only select nodes.  By default, it will return all nodes stored in the index.  Query options (defined by String[] queryOptions) can be used to select attributes by relative path. For example: '//document' as a query option would select all documents. The query option value {'@name'} would select only the name for every document. This is an example of limiting the set of attributes brought back.


All author information for documents

  • '//document' {'author'} (The indexed attributes for the author node are returned)
  • '//document' {'..'} (The parent node of the document)
  • '//document' {'author@firstname', 'author@lastname', '@title', '@description'} (The indexed attributes for the author node are returned)

The result set will contain only values for the specified relative paths.  The node's @id attribute will always be included.

Canned Queries

A simple request to execute a named query. Canned queries will be stored in their own workspace or in a given work space.
They are most likely to be reused across all workspaces.

public ResultSet query(StoreRef[] stores, QName queryId, String[] queryParameters)

Result Set

* Will also have index based and column name based look up

    * Get the relative paths to all the elements contained in this result set
   String[] getPropertyPaths();

    * Iterator over Rows
    * (Avoiding generics for 1.4)
   RowIterator getRows(); // Typed iterator with nextRow() returning Row

    * Get the size of the result set
   int length();

    * Get the id of the node at the given index
   Id getId(int n);

    * Get the score for the node at the given position
   Score getScore(int n);

    * Generate the XML form of this result set
   Dom getXML(int page, int pageSize, boolean includeMetaData);

    * Generate as XML for Reading
   Stream getStream(int page, int pageSize, boolean includeMetaData);

    *  toString() as above but for the whole set
   String toString();

   ResultSetMetaData getMetaData();

   Values[] getValues();  

   Value getValue();

   Id getId();

   Score getScore(); // Score is score   rank   potentially other stuff

   ResultSet getResultSet();

    String[] getPropertyPaths();
    PropertyDefinition[] getPropertyDefinitions();

    WorkspaceId getWorkspaceId();
    QueryLanguage getQueryLanguage();
    String getQuery();
    QName getQueryId();
    QueryParameters getQueryParameters();   

PagedResultSetMetaData extends RequeriableResultSetMetaData
    int getPageSize();
    int getPage();
    int getStartIndex();
    int getEndIndex();

Query Languages

  1. Based on lucene
    • The search will be based on the current lucene QueryParser (with bind variables)
    • It will include wild cards at the start of the query
    • It should be used with our field based analyser
    • Path and category search phrases will support simple structured data queries based on path with no attribute axis predicates
      • PATH:'/woof'
      • PATH:'/woof//*'
      • PATH:'//woof'
      • PATH:'//woof//*
      • CATEGORY:'/assetclass/*'
  2. XPath as defined in JCR 170 (with bind variables)
  3. SQL as defined in JCR 170 (with bind variables)
  4. Anything else
  5. Bind variables
    • Substitution anywhere in the query pattern for the above
    • Based on XSLT/XPath variable use
    • $variable
      • variable name terminated by white space
    • {$variable}
      • explicit variable name delimitation.
    • Variables are made up of an optional name space and name
      • Use name space for reusable variables (well known parameters with a common definition)
      • Use no name space for query specific parameters that are not exposed elsewhere

Canned Query Definition

Allows for the idea of well known parameters (e.g. product).
Parameter definitions could be in their own right.
Queries and Parameters etc will be defined by type.
Repository wide definitions will exists in the query workspace.
The contents of which may be cached.

Other queries may be defined at the top level of any workspace.

It is not intended to allow queries from one workspace to run in another.
If this is required they should be common and moved to the query workspace.

  1. QName
  2. Parameter definitions
    1. QName 
    2. PropertyType
    3. Default ??
  3. Uses parameter - by detection - prefers local parameter definitions to global.
  4. Query String (used to select nodes)
  5. Attribute paths  (used to select properties by path off the selected nodes)