The remaining components of the query all reside in collapsable borders that can be expanded or collapsed by clicking on the arrow in the title of the component. For example, if you click on the arrow next to the "Imports" label, the imports editor will expand to allow editing.
The editors for each of these components have a plus and minus icon, for use in adding or removing elements from the component. Furthermore, double-clicking in any blank space in the component will add a new row that can then be edited.
The ordering editor provides a means of specifying the ordering of the results of the query. The "field" column will contain the name of the field on which to order, and the "direction" field will be either "ascending" or "descending".
The parameters editor allows the user to specify one or more parameters for the query to use. The "type" of the parameter is the class of the parameter, the "name" of the parameter is the name by which the parameter will be referred in the filter editor, and the value is the value of the field. For example, if you add a new row with the type set as "String", and name set as "fnameParam", and the value set to "Marc", then in the filter editor you could enter the filter (against some class that has a field named "firstName") firstName == fnameParam. The query will then be executed as if the filter had read firstName == "Marc". For more details on using parameters in queries, see Chapter 11, Query.
Some other features of the parameter editor are:
Strings and numbers are entered literally.
Collection parameters can be specified as being separated by commas. For example, your filter could read namesParam.contains(firstName), and the parameter could be entered with the type set to "java.util.List", the name set to "namesParam", and the value set to "Steve,Abe". This query will find all people whose first name is "Steve" or "Abe".
Persistent parameters (i.e., parameters that are of a persistent type) are entered using the stringified object id of the type. For example, if the type of the parameter is "Person", the name of the parameter is "personParam", and the value of field is "com.mycompanyt.Person-14760", then the filter employees.contains (personParam) (executed against some class that has a collection of Person instances called "employees") will execute the query with that persistent parameter.
It is possible to drag a row from the JDO Results browser into the parameters table, which will cause a new parameter to be declared with that object id. For example, if the results browser is showing a Person instance, dragging that instance will declare a new parameter with type set to "Person", name set to an auto-assigned name "personParam", and the value set to the stringified object id of the instance. This can greatly ease the tedium of declaring persistent parameters, since you do not need to type in what can be a lengthy stringified object id.
The imports editor allows you to declare imports so that you do not need to enter the complete package name in the variables or parameters editor. For example, if you enter a row with com.mycompany.*, you can then just enter Company as the type of a parameter without having to fully qualify the name. Another handy use is to add java.util.*, so that you do not need to fully qualify collection parameter declarations (such as java.util.Set).
The variables editor allows you to declare variables to use in the query. For example, when executing against some "Company" class that has a collection called "employees" that contains instances of "Employee", you can declare a variable of type "Employee" and name "emp", and the filter can be entered as employees.contains(emp) && emp.firstname == "Patrick", which fill find all Company instances that have an employee whose first name is "Patrick".
The aggregates and projections editor allow you to edit these features of the query. For details on using aggregates and projections in queries, see Chapter 11, Query. For example, you can obtain only the "name" fields by executing a query against a Company with the "field/expression" row of the Aggregates and Projections set to "name" (the "alias" field can optionally be left blank). Another example is that you can execute a query against a "Person" class with an aggregate row set to "sum(salary)".
The fetch configuration editor allows you to specify the fetch groups that will be used when executing the query. For more details about fetch configuration, see Section 10.5, “Fetch Configuration”.