Java data Object JDO 2.0 Query Language features _JSP programming

The improvement of query language is an important part of JDO2.0 specification, and this paper expounds some new functions provided by JDO2.0 from a higher level. As the JDO2.0 norm has not yet entered the open draft State, nothing has been finalized and everything is likely to be subject to change. However, JDO2.0 will soon be in the final stages, and the query feature mentioned here is the JDO2.0 Expert group (translator: David Jordan is an important member of the Expert Group) who spends the most time and is relatively the most stable. Therefore, I have reason to believe that the final specification and the description here will be basically consistent.

If your readers feel that this article omits some important features, it is recommended that you immediately go to the JDO forum (http://www.jdocentral.com/forums/index.php?showforum=10 ) to present and discuss it. Here we need to thank JDO2.0 Spec leader Craig Russell for empowering me to expose the new features of these JDO2.0 query languages.

　　Query results

We start with the most in-depth improvements. In JDO1.0, the query result is always a collection of instances of the class you specify. Consider the following UML class diagram, which expresses the relationships between classes A, B, C, and D four:

You can create a query for Class A, refer to Class B by contains (), and then refer to Class C with another layer of contains (), and finally use a "." The operator references to Class D. But the final returned collection will only contain object instances of Class A, and if you want to derive other classes from the results, you must obtain the related other class objects individually by reference to Class A. If your query criteria contain a class B, C, or D constraint, then you must repeat the constraints in the Java code when you refer to the other class objects through a Class A object in the result set, which means you have to repeat the restrictions in Java and JDOQL. Furthermore, you may only be concerned with Class D objects that satisfy the query criteria, and do not want intermediate B and C objects to be created by the JDO low-level to save memory or related resources.

In JDO2.0, you are no longer bound by these limitations. You can return:

One or more fields of a data class (persistentcapable)
Class objects other than the candidate class
Statistical data

This means that you can return a, B, C, D objects, or some of their fields, or the mixed results of both. You can also calculate statistical results such as Min or Max. Basically, you can return whatever results you want.

When you create a query, you can specify a "result specification" to specify what content to return. It is a comma-delimited "result Expression" that contains one or more. The resulting expression can be:

This keyword, which represents an object instance that returns a candidate class. This is the same field as JDO1.0, which indicates the value of a candidate class or a field of a reference class, such as a address.street.name field expression, that represents a result variable derived from several arithmetic operations of JDO predefined for multiple fields, representing an intermediate variable reference expression that appears in a query condition , that is, the passage in JDO1.0 "." operator, you can get any result you want by using the combination of the above expressions. "----statistical expressions

JDO2.0 supports the following statistical functions:

COUNT (expression), which can be an expression of this
sum (numeric field expression), "numeric field expression" can be the result of a numeric type obtained by the operation of a field or field
Min (numeric field expression)
Max (numeric field expression)
AVG (numeric field expression)

The query results are specified through the following APIs:

void Javax.jdo.Query.setResult (String result)

If you do not call this method, or if the parameter is null, the object instance of the candidate class (equivalent to "This" is set to "this") is returned, that is, the return result of the JDO1.0. If you specify only a unique result expression, the element type of the returned collection is the same as the type of the result. In addition, by default, if more than one result expression is specified, the returned collection element type will be object[].

You can distinct the beginning of the result definition string to ensure that the result is not duplicated. If the result definition string contains several expressions, then distinct can guarantee that there will be no duplicate data sets in the result set.

Each result expression can specify a name, and for a simple field, the system defaults to the name of the field as the name of the item in the result. For complex expressions, you can use the following syntax to specify a name:

Result_expression as Name

　　
The use of a name allows the item in the result to be set and used as a property in the result class. You can specify a result class to return the query results. If the query result is a single value, the result class can be any of the classes supported by JDO (Integer, Double, String, BigInteger, BigDecimal, Java.util.Date, Java.sql.Date, Java.sql.Time, Java.sql.Timestamp). The method of setting the result class in query is:

void Setresultclass (Class resultclass)

If the query result contains more than one result expression, you can define a result class that preserves the data in the result, and the class must have a constructor without parameters. In addition, each result expression must correspond to a property in this class, whether it is a public field or a public setxxx () method, and the direct or bean-style property name is consistent with the names of the resulting expressions in the query results.

Group Operations (Grouping)

The statistics feature can be used in a grouping operation. JDO2.0 provides a group by and a HAVING clause similar to SQL. Query method:

void Setgrouping (String groupspec)

The principle used to specify grouping. The Groupspec parameter contains one or more comma-separated grouping expressions and can be followed by a filter condition that begins with "having". After this method is called, each result expression entry for the Setresult () parameter must be an entry in the Groupspec, or an operation result of one or more items in Groupspec. Results for all Groupspec items are grouped together in the same group (same result record). The filter condition of a HAVING clause can contain a Boolean result's judgment statement or a statistical operation on a grouping expression. As with SQL, a HAVING clause is used for conditional filtering of a grouped result set.

　　 Uniqueness (Uniqueness)

A lot of people have been wondering why query execution results are objects of object type, because it makes it inconvenient for developers to manually force the results into collection. The query results in JDO1.0 typically have multiple elements, but the JDO Expert Group plans to include support for queries that return a single value result in JDO2.0, and then defines the execution result of query as type object.

You can sometimes execute a query that you're sure will only have one (such as the total number of statistics or a member account that has a unique index, and so on), and in JDO2.0 you can call the Query method to declare:

void Setunique (Boolean unique)

When you pass in "true", the result of query execution is a separate value object, and the result is null if no results are returned. If the JDO discovers that the query results return more than one record, an exception is thrown.

　　 limit the size of the returned results

When designing the user interface, we often display a subset of the result set (such as pagination display or only the first 10 or so). For performance and efficiency, you will probably need to limit the range of return results. The method of query can accomplish this:

void SetRange (int frominclusive, int toexclusive)

The result set returned by this method contains only the first frominclusive to article toExclusive-1 of the original result set.

　　 the new filter condition operator

Some new operators are added to the JDOQL to perform operations on references, maps, strings, and numbers. The instanceof operator returns a Boolean value that allows you to filter the object of a specified class, and the ContainsKey (object) function and Containsvalue (object) that return Boolean values to access the MAP element.

A number of functions are added to the string processing, toLowerCase () and toUpperCase () perform case conversions, and the following functions are used to find substring locations and to obtain substrings:

int IndexOf (String) int indexOf (string, int) string substring (int) string substring (int,int)

In addition, the method of string:

Boolean matches (String pattern)

Used to perform a regular match. Only limited matching capabilities are available at this time. “.” and ". *" can represent wildcard characters, while "(? i)" indicates matching is case-insensitive.

For numeric fields, JDO2.0 adds two functions:

Math.Abs (numeric) math.sqrt (numeric)

　　 predefined queries (Named Queries)

You can declare commonly used JDOQL query statements in the JDO descriptor (metadata) so that you do not have to embed the query in the Java source code. This provides some flexibility, such as writing query statements to a configured text file, and modifying the file directly without changing the Java source code. Each query in a descriptor has a name, and to execute a query, you can use the following method to create the query:

Query Newnamedquery (Class cls, String queryname)

JDO will search for descriptors to find the corresponding predefined query statements and generate the corresponding query object.

　　 accessing static fields (fields)

You will be able to access constants declared in the data class in public static final in the JDOQL. Like what

public static final int FEMALE = 0; public static final int MALE = 1; public static final int UNKNOWN = 2;

In a query, you use a filter condition similar to "salary > 5000.0 && gender = = MALE".

　　 Bulk deletion (deletion by Query)

In JDO1.0, to delete an object, you must first load it into memory and then delete it, however, in many cases, you do not need to access the object before you delete it, which is less efficient. In JDO2.0, several methods of query are provided to delete a set of objects that match the query criteria:

Object Deletepersistentall (object[] Parameters) object Deletepersistentall (Map parameters) object Deletepersistentall ()

The objects of this query result are all deleted from the database. These methods return a collection of deleted objects. Your program can decide if you want to access the deleted objects one at a a while. If you do not access these objects, the performance of query execution will be unaffected, in other words, these objects will not be generated in memory.

Vendor-Extended Query characteristics

JDO vendors can provide JDOQL with a wide variety of special query capabilities. Each vendor can define a set of extended features that belong to the vendor. If you need to use one of these features, you need to add the vendor's extensions to the program's operating environment. Each extension has a name and an optional value. You can set each extension individually or set multiple extensions at once. The following methods of query are used to set vendor extension attributes:

void Setextensions (Map extensions) void AddExtension (String key, Object value)

　　 SQL Direct Access

If the JDO2.0 query feature does not meet your needs, the following conditions are true:

Your application runs on the relational database
　　
The query you need has SQL statements that you can implement

You know the mapping details from your class model to the database

You can create an SQL query by invoking the Persistentmanger method:

Query NewQuery (String language, Object query)

　　
Each parameter needs to be set to "Javax.jdo.query.SQL", and query is a specific SQL statement. If your query needs to return an instance of the class, the SQL statement must return the corresponding primary key field for that class. When using direct SQL, the JDOQL-supplied function will not be used, or it will throw an exception jdouserexception, for example, you cannot set a filter condition string, sort declaration, or variable declaration on the query. When using SQL queries, parameters are unspecified types, in SQL statements with "?" Representations, and are bound in the order in which they appear.

　　 Concluding remarks

As readers have seen, JDO2.0 has added a lot of new functionality and features to the query, and I think the query result definition is the biggest improvement. As I said at the beginning of the article, this part of the change is currently the most stable part of the JDO2.0 and will not change much. Vendors can start to offer many of these features, regardless of how the rest of the JDO2.0 that the panel is discussing will change.

The query functionality described here and a decoupling/hooking (Detach/attach) mechanism for the JDO application of a multi-tiered architecture will allow JDO to occupy more markets, provided that the JDO2.0 provides a standard object/relationship mapping. To this point have a deep understanding of the manufacturers will spare no effort to launch the first stable, complete and efficient JDO2.0 products. JDO will be the first API for application development based on database storage and management, and developers will enjoy object-oriented model design and efficient data storage management systems.