Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you about how to analyze iBATIS dynamic mapping. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

IBATIS dynamic mapping is used in complex query process, and we often need to determine the query conditions according to the user's choice. Here, it is not only the parameters in SQL, but also the fields and qualifications included in the Select statement that may change. In typical cases, such as on a complex composite query page, we must determine the combination of conditions for the query according to the user's selection and input.

A typical page for iBATIS dynamic mapping is as follows:

For this combined query page, we should generate different query statements for it according to what the user chooses to fill in. If the user submits the query request without filling in any information, we should return all records:

Select * from t_user

If the user only fills in the name "Erica" on the page, we should generate something like:

SQL query statement for Select * from t_user where name like'% Erica%';.

If the user only fills in the address "Beijing" on the page, we should generate something like:

SQL of Select * from t_user where address like'% Beijing% ";.

If the user fills in both the name and address ("Erica" & 'Beijing'), we should generate something like:

SQL query statement for Select * from t_user where name like'% Erica%' and address like'% Beijing%'.

For ORM implementations such as iBATIS, which requires pre-specified SQL statements, the traditional approach is to determine the input parameters through the if-else statement and then invoke different statement definitions according to the user's choice. For the simple case above (the arrangement and combination of two query conditions, a total of four cases), the repetitive definition of statement has been tiresome, while for easily having seven or eight query conditions, or even more than a dozen query conditions

In terms of arrangement and combination, the trivial and repeated definition of statement is really unbearable.

With this in mind, iBATIS introduces a dynamic mapping mechanism, that is, in the definition of statement, according to different

IBATIS dynamically maps query parameters and sets the corresponding SQL statement.

Take the example above as an example:

Select

Id

Name

Sex

From t_user

(name like # name#)

(address like # address#)

Through the dynamic node, we define a dynamic WHERE clause. The lieutenant general in this WHERE clause

It may contain two criteria for the name and address fields. Whether these two fields are included in the retrieval depends on the query conditions provided by the user (whether the field is empty [isNotEmpty]).

For a typical Web program, we get the field name in the form through HttpServletRequest and set it to the query parameters, such as:

User.setName (request.getParameter ("name"))

User.setAddress (request.getParameter ("address"))

SqlMap.queryForList ("User.getUsers", user)

When executing queryForList ("User.getUsers", user), ibatis is based on the configuration text

The SQL dynamic generation rules are set in the component, and the corresponding SQL statements are created.

In the above example, we specify the name and address attributes by determining the node isNotEmpty

Dynamic rules of sex:

(name like # name#)

The semantics of this node is that if the "name" attribute of the parameter class is not isNotEmpty, that is, it is not empty

String ""), the decision condition (name like # name#) is included in the generated SQL Where sentence, which

# name# will be populated with the value of the name property of the parameter class.

The decision generation of the Address attribute is exactly the same as the name attribute, so I won't repeat it here.

In this way, we simply realize the dynamic generation of statement decision clauses by introducing dynamic nodes into the SQL definition, which will bring great convenience to complex combinatorial queries. The definition of decision nodes can be very flexible, and we can even use nested decision nodes to achieve complex dynamic mapping, such as:

(name=#name#address=#address#)

This definition stipulates that only when the user provides the name information can the query be combined with the address data (if only the address data is provided and the name information is ignored, it will still be regarded as full retrieval). The prepend attribute in the Dynamic node and the decision node, indicating that the SQL clause defined in this node is specified in the

The prefix that appears in the principal SQL. Such as:

(name like # name#)

(address like # address#)

Assuming that the value of the "name" attribute is "Erica" and the value of the "address" attribute is "Beijing", a SQL clause similar to the following will be generated (the actual run time will generate a placeholder PreparedStatement and then populate it with data):

WHERE (name like 'Beijing') AND (address like' Beijing')

The statement after WHERE is defined in the dynamic node, so it is prefixed with the prepend setting ("WHERE") of the dynamic node, and the "AND" is actually the prepend setting of the isNotEmpty node corresponding to the address attribute, and it * defines the SQL clause in the corresponding node. As for the isNotEmpty node corresponding to the name attribute, since iBATIS automatically determines whether to append the prepend prefix, here (name like # name#) is the * conditional clause in the WHERE clause without the AND prefix, so it is automatically omitted.

Decision nodes are not limited to the rich decision definition functions provided in isNotEmpty,iBATIS. Decision nodes are divided into two categories:

Zero unary decision

The unary decision is the determination of the attribute value itself, such as whether the attribute is NULL, whether it is null, and so on.

IsNotEmpty in the above example is a typical unary decision.

The unary decision nodes are:

Node name description

Whether this property is provided in the parameter class

On the contrary

Whether the attribute value is NULL

On the contrary

If the property is Collection or String, whether its size is the opposite.

Binary decision

Binary decision has two decision parameters, one is the attribute name, but the decision value, such as

(age=#age#)

Where property= "age" specifies the attribute name "age", and compareValue= "18" indicates that the decision value is "18". The semantics of the node isGreaterThan determined above is: if the age attribute is greater than 18 (compareValue), add a (age=#age#) condition to the SQL.

The above is the editor for you to share how to analyze iBATIS dynamic mapping, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.