JDO2.0 query language new features
David Jordan
(Original: http://jdocentral.com/jdo_articles_20040329.html)
The improvement in query language is an important part of the JDO2.0 specification, which explains some new features provided by JDO2.0 from a higher level. Since the JDO2.0 specification has not yet entered the state of public draft, there is currently no content to be finalized, and everything may face change. However, JDO2.0 will quickly enter the final stage, and the query feature mentioned here is a JDO2.0 expert group (translator Note: David Jordan is an important member of the expert group) spends the most time, and is relatively stable. Therefore, I have enough reason to believe that the ultimate specification will be basically consistent with the description here.
If the readers feel that this article is missing some important features, it is recommended to immediately go to the JDO Forum (http://www.jdocentral.com/forums/index.php?showforum =10) and discuss it. Here we need to thank JDO2.0 specification leaders Craig Russell authorized to disclose new features of these JDO2.0 query languages.
search result
We first introduced from the most in-depth improvement. In jdo1.0, the query result is always a collection of instances of the class you specify. Consider the following UML class diagram, it expresses the relationship between the four classes of A, B, C, D:
You can create a query for the A class, reference to the Class B by contains (), and then use another layer Contains () to reference Class C, and finally use one "." Operator reference to the D class. However, the final returned collection will only contain an object instance of the Class A, and if you want to get other classes from the results, you must obtain the related other types of objects one by one by reference. If your query is constrained, when you reference other class objects in the result set through the Class A object, you must re-repeat these constraints in the Java code, that is, you have to Declaration restrictions in Java and JDOQL. Moreover, you may only care about the D class object that meets the query criteria, and does not want the middle B, Class C objects to create memory or related resources by the JDO underground.
In JDO2.0, you will never be bound to these limitations. You can return:
Other class object statistics other than one or more fields of the PersistentCapable
This means you can return A, B, C, C, D class objects, or some of their fields, or blending results of both. You can also calculate statistical results similar to MIN or MAX. Basically, you want to return any results.
When you create a query, you can specify a "result definition" to specify what kind of content returned. It is a "resulting" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" Results can be:
The THIS keyword indicates an object instance that returns the candidate class. This is the same as the JDO1.0, indicating a value of a field of the candidate class or a reference class, such as the address.street.name field expression, which represents several multi-fields for jdo predefined several arithmetic operations. Result variables, representative of an intermediate variable that appears in query conditions, that is, the reference statistics between the "." Objects in JDO1.0.
You can get any result you want by using the combination of these results expressions.
JDO2.0 supports the following statistics:
Count (expression), the expression can be this SUM (digital field expression), "digital field expression" can be a digital result of a digital type obtained through a field or field, MAX (digital field expression) max (Digital Field Expression) AVG (Digital Field Expression) Specifies to the results of the query to pass the following API:
Void javax.jdo.query.setResult (String Result)
If you do not call this method, or the parameter is NULL, return the object instance of the candidate class (equivalent to setting to "this"), that is, the return result of JDO1.0. If you only specify a unique result expression, the elements of the collected collections are consistent with the type of the result. In addition, in the default mode, if multiple result expressions are specified, the returned set element type will be Object [].
You can guarantee the results not repeated on the beginning of the result definition string. And if the result definition string contains several expressions, DistINCT ensures that there is no repetitive data group in the result set.
Each result expression can specify a name. For a simple field, the system will default to the name of this item as the name of the field. For complex expressions, you can use the following syntax specified name:
Result_expression As Name
The use of the name can make the item in the result as an attribute in the result class for setting and use. 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 JDO support class (Integer, Double, String, Biginteger, BigDecimal, Java.util.date, java.sql.date, java.sql.time, java.sql. TimeStamp). The way to set the result classes in Query is:
Void SetResultclass (Class Resultclass)
If the query result contains multiple result expressions, you can define a result class to reserve the data in the results, which must have a parameterless constructor. In addition, each result expression must correspond to an attribute in this class, whether it is a PUBLIC field, or a PUBLIC's setXX () method, and this direct or bean style property name and query results The name of the expression is consistent.
Group Operation (Grouping)
The statistics can be used in a packet operation. JDO2.0 provides Group By and Having clauses similar to SQL. Query method:
Void setGrouping (String Groupspec)
The principle used to specify the packet. The GroupSpec parameter contains one or more packet expressions separated by commas, and can also keep up with a filter condition starting with "haVing". After calling this method, each result of the setResult () parameter must be one of GroupSpec, or one or more of GroupSpec. The value of all the value of all GroupSpec items is attributed in the same group (recorded in the same result). The filtering condition of the Having clause can contain the judgment statement of the Boolean result or a statistical calculation of the packet expression. Like SQL, the Having clause is used to filter the result set after the packet.
Uniqueness
Many people have been strange why Query's execution is an object of an Object type, because it is necessary to convert the results into the inconvenient to convert the results to the developers. The query results in JDO 1.0 generally have multiple elements, but the JDO expert group plans to join the support of the query that returns a single value result in JDO2.0, so that Query's execution result is defined as an Object type. You sometimes execute a query for your identification results (such as total statistics or membership accounts with unique indexes, etc.), in JDO2.0, you can call the Query method to declare:
Void setUnique (Boolean Unique)
When you pass "True", Query executes the result will be a separate value object, if there is no result returns, the result is NULL. If the JDO finds that the query result returns a plurality of records, it will throw an exception.
Limit the size of the return result
When designing the user interface, we often display a subset of part of the result set (such as paging display or only the top ten of the top ten). For performance and efficiency, you will need to limit the range of returning results. Query's method can accomplish this:
Void SetRange (int frominclusive, int toexclusive)
The result set returned by the method only contains the origin of the original result set to the TOEXCLUSIVE-1.
New filter condition operator
Some new operators are added to JDOQL to perform operations for reference, MAP, strings, and numbers. The InstanceOf operator returns a boolean value, allows you to filter an object of a specified class; also returns the containskey (Object) function of the Boolean value and ContainSValue (Object) to access the Map element.
String handlers have added a lot of functions, TOLOWERCASE () and TouPpercase () complete the case switch, and the following functions are used to find subtrings and obtain subtrings:
Int indexof (string)
Int indexof (int) String Substring (int) SUBSTRING (INT, INT)
In addition, String method:
Boolean Matches (String Pattern)
Used to perform regular matching. It is currently only available for limited matching. "." And ". *" Can represent wildcards, and "(? I)" means that matching is not case sensitive.
For digital fields, JDO2.0 adds two functions:
Math.Abs (Numeric) Math.SQRT (Numeric)
Predefined query (Named queries)
You can declare a commonly used JDOQL query statement in the JDO descriptor (Metadata) so you don't have to embed the query into the Java source code. This provides some flexibility, such as writing a query statement into a configured text file, and you can change the file directly without changing the Java source code. Each query in the descriptor has a name, and when a query is executed, you can use the following method to create a query:
Query NewNamedQuery (Class CLS, String QueryName)
JDO will search for a descriptor to find the corresponding predefined query statement and generate the corresponding Query object.
Access Static Field (Static Fields)
You will be able to access the constant declared in the public static final mode in the data class in JDOQL. such as
Public static final int material = 0; public static final int us = 1; PUBLIC static final int unknown = 2; filter conditions similar to "Salary> 5000.0 & &nder == Male" in the query.
Batch Remove (Deletion By Query)
In jdo1.0, you want to delete an object, you must load it into memory, then delete, but in many cases, you don't need to access the object before deleting, such a relatively inefficient. In JDO2.0, several methods of Query are provided to delete a set of objects that meet the query conditions:
Object deletePersistentall (Object [] parameters) Object deletePersistentall (map parameters) Object deletepersistentall ()
The object of this query result will be removed from the database. These methods returns a collection of deleted objects. Your program can decide whether you need to access the object being removed. If you don't access these objects, Query executes will not be affected. In other words, these objects will not be generated in memory.
Verfe for manufacturers expanded
JDO vendors can provide a wide range of special query features to JDOQL. Each manufacturer can define a set of extensions belonging to the manufacturer. If you need to use the features, you need to add the manufacturer's extension to the program running environment. Each extension has a name and an optional value. You can set each extension separately, or set multiple extensions at once. Query's method is used to set the manufacturer extension feature:
Void setExtensions (Map Extensions) Void Addextension (String Key, Object Value)
SQL direct access
If the Query function of JDO2.0 cannot meet the needs, and the following conditions are satisfied:
Your app runs on the relational database You need a query with a SQL statement to realize the map details from your model to the database.
You can create a SQL query, the method is to call the method of PersistentManger:
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 of the class. When using direct SQL, the function provided by JDOQL will not be used, otherwise the exception JDOUSEREXCEPTION is thrown, for example, you cannot set the filter condition string, sort declaration, or variable declaration of the Query. When using the SQL query, the parameters are not specified type, "?" In the SQL statement, "?" Is indicated, and the order in appears is bound.
Conclude
Readers have seen that JDO2.0 adds a lot of new features and features to query statements, I think the query results are defined as the biggest improvement. As I said at the beginning of the article, this part of the change is currently the most stable part in JDO2.0, and there will be no big changes. Manufacturers can start providing a lot of such features, do not consider how the Group of JDO2.0 is also discussed in discussion.
Under the premise of jdo2.0 to provide standard object / relationship mapping, the query function described here and an off-hook / hook (Detach / Attach) mechanism for multi-layer structure will make JDO occupy more markets. Vendors who have deep experiences will spare no effort to take the lead in launching stable, intact, and efficient JDO2.0 products. JDO will be the first API based on the application development of database storage and management, and developers will enjoy object-oriented model design and efficient data storage management systems. David Jordan created Object Identity to provide JDO consulting, training and software project custom development services. He is an active molecule added at the beginning of the JDO expert group. David Jordan and Craig Russell work together to write authority "Java Data Objects" and published by O'Reilly & Associates.
The copyright of this translation belongs to the author, but welcome to reprint, the premise is to indicate the source and the original author. In addition, welcome to some of my articles in my column, and make valuable comments!
