Java Doc for VersantQuery.java in  » Testing » PolePosition-0.20 » com » versant » core » jdo » Java Source Code / Java DocumentationJava Source Code and Java Documentation

This interface provides additional Open Access specific query properties. There are two ways to use these properties in your applications:

1. Cast the Query returned by PersistenceManager.newQuery(...) to a VersantQuery and call the setXXX methods. This is clear in code but non-portable to other JDO implementations.
2. Add a 'String versantOptions' parameter to the query and specify a semicolon delimited String of property=value pairs when the query is executed. Portability is maintained as other JDO implementations should ignore this parameter.

Example using casting:

 VersantQuery q = (VersantQuery)pm.newQuery(Item.class);
 q.setFetchGroup("codeOnly");
 q.setRandomAccess(true);
 Collection ans = (Collection)q.execute();
 ...
 

Example using versantOptions parameter:

 Query q = pm.newQuery(Item.class);
 q.declareParameters("String versantOptions");
 Collection ans = (Collection)q.execute("fetchGroup=codeOnly;randomAccess=true");
 ...
 

Normally when size() is called on the Collection returned by executing a non-randomAccess Query all of the results are fetched in one operation to detirmine the size of the collection.

Register classes that will cause the cached results of this query to be evicted if any of its instances are modified.

You might want to use this for a large JDOQL query if you know that caching the results will not benefit the application. Or you could use it to cache the results of an SQL query.
See Also:   VersantQuery.setEvictionClasses(int[])

Normally when size() is called on the Collection returned by executing a non-randomAccess Query all of the results are fetched in one operation to detirmine the size of the collection. If this property is true then a 'select count(*) ...' version of the query is used to count the results. Subsequent calls to to size() after the first call will revert to normal behaviour and resolve all of the results.

Note that the actual number of results might differ to those first returned by size() when this option is used. This can happen if new rows that meet the filter criteria are inserted after the 'select count(*)...' query has run but before the normal 'select ...' to fetch the data. This may be possible even in a non-optimistic transaction depending on how the database handles locking.

Register classes that will cause the cached results of this query to be evicted if any of its instances are modified. These replace any previously set classes. JDO Genie will automatically pickup the candidate class and classes involved in the filter or ordering. You only need to call this method if you are using inline SQL to touch tables for classes not otherwise involved in the query. Here is an example:

Query q = pm.newQuery(Order.class);
String aclCheck = "$1 in (select $1 from acl where user_id = " + userId + ")";
q.setFilter("owner.sql(\"" + aclCheck + "\")");
((VersantQuery)q).setEvictionClasses(new[]{Acl.class}, true);
// make sure query result is evicted if acl table(class) changes
...

Parameters:
  includeSubclasses - Recursively add subclasses (if any)
See Also:   VersantQuery.setEvictionClasses(int[])