Skip to content
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Commit 4eeb56f

Browse files
authoredMay 6, 2021
Merge pull request #358 from jeffgbutler/final-doc-updates
Doc Updates for Release
2 parents bb0d1e4 + a06d306 commit 4eeb56f

File tree

8 files changed

+203
-79
lines changed

8 files changed

+203
-79
lines changed
 

‎CHANGELOG.md‎

Lines changed: 34 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22

33
This log will detail notable changes to MyBatis Dynamic SQL. Full details are available on the GitHub milestone pages.
44

5-
## Release 1.3.0 - Unreleased
5+
## Release 1.3.0 - May 6, 2021
66

77
GitHub milestone: [https://github.com/mybatis/mybatis-dynamic-sql/issues?q=milestone%3A1.3.0+](https://github.com/mybatis/mybatis-dynamic-sql/issues?q=milestone%3A1.3.0+)
88

@@ -13,13 +13,14 @@ The major themes of this release include the following:
1313
1. Add support for subqueries in select statements - both in a from clause and a join clause.
1414
1. Add support for the "exists" and "not exists" operator. This will work in "where" clauses anywhere
1515
they are supported.
16-
1. Refactor and improve the built-in conditions for consistency (see below)
17-
1. Continue to refine the Kotlin DSL. Most changes to the Kotlin DSL are internal and should be source code
16+
1. Refactor and improve the built-in conditions for consistency (see below). There is one breaking change also
17+
detailed below.
18+
1. Continue to refine the Kotlin DSL. Many changes to the Kotlin DSL are internal and should be source code
1819
compatible with existing code. There is one breaking change detailed below.
1920
1. Remove deprecated code from prior releases.
2021

21-
### Built-In Condition Refactoring
22-
All built-in conditions have been refactored. The changes should have no impact for the vast majority of users.
22+
### Built-In Condition Refactoring and Breaking Change
23+
All built-in conditions have been refactored. The changes should have little impact for the vast majority of users.
2324
However, there are some changes in behavior and one breaking change.
2425

2526
1. Internally, the conditions no longer hold value Suppliers, they now hold the values themselves. The SqlBuilder
@@ -31,13 +32,14 @@ However, there are some changes in behavior and one breaking change.
3132
for a similar purpose.
3233
1. The new "filter" method works a bit differently than the "when" method it replaces. The old "when" method could not
3334
be chained - if it was called multiple times, only the last call would take effect. The new "filter" methods works
34-
as it should and every call will take effect.
35+
as it should and every call will take effect. This allows you to construct map/filter pipelines as you would
36+
expect.
3537
1. The new "map" method will allow you to change the datatype of a condition as is normal for a "map" method. You
3638
can use this method to apply a type conversion directly within condition.
3739
1. All the "WhenPresent" conditions have been removed as separate classes. The methods that produced these conditions
3840
in the SqlBuilder remain, and they will now produce a condition with a "NotNull" filter applied. So at the API level
3941
things will function exactly as before, but the intermediate classes will be different.
40-
1. One breaking change is that the builder for List value conditions has been removed without replacement. If you
42+
1. One **breaking change** is that the builder for List value conditions has been removed without replacement. If you
4143
were using this builder to supply a "value stream transformer", then the replacement is to build a new List value
4244
condition and then call the "map" and "filter" methods as needed. For example, prior code looked like this
4345

@@ -62,9 +64,31 @@ However, there are some changes in behavior and one breaking change.
6264
```
6365
We think this is a marked improvement!
6466

65-
### Breaking Change for Kotlin
67+
### Kotlin DSL Update and Breaking Change for Kotlin
6668

67-
In this release the Kotlin support for `select` and `count` statements has been refactored. This will not impact code
69+
The Kotlin DSL continues to evolve. With this release we have fully built out the DSL, and it is no longer necessary
70+
to use any functions in `org.mybatis.dynamic.sql.SqlBuilder`. The advantages of this are many and are detailed on the
71+
Kotlin overview page in the documentation. Many functions in `SqlBuilder` have been replaced by
72+
top level functions the `org.mybatis.dynamic.sql.util.kotlin.elements` package. In most cases you can switch to the
73+
native Kotlin DSL by simply changing the import statements. For example, you can switch usage of the `isEqualTo`
74+
function by changing
75+
76+
```kotlin
77+
import org.mybatis.dynamic.sql.SqlBuilder.isEqualTo
78+
```
79+
80+
to
81+
82+
```kotlin
83+
import org.mybatis.dynamic.sql.util.kotlin.elements.isEqualTo
84+
```
85+
86+
Several functions that accepted supplier arguments are not present in the Kotlin DSL. This is to avoid difficult
87+
and confusing method overload problems for methods that did not offer any real benefit. If you were using one of these
88+
methods in the Java DSL, then in the Kotlin DSL you will have to change the function argument from a supplier to the
89+
actual value itself.
90+
91+
A **breaking change** is that Kotlin support for `select` and `count` statements has been refactored. This will not impact code
6892
created by MyBatis generator. It will have an impact on Spring/Kotlin users as well as MyBatis users that coded joins or
6993
other queries directly in Kotlin. The difference is that the `from` clause has been moved inside the lambda for select
7094
and count statements.
@@ -84,7 +108,7 @@ The new code looks like this:
84108
}
85109
```
86110

87-
This change makes the Kotlin DSL a bit more consistent and also makes it easier to implement subquery support in the
111+
This change makes the Kotlin DSL more consistent and also makes it easier to implement subquery support in the
88112
Kotlin DSL.
89113

90114
### Added

‎checkstyle-override.xml‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
<?xml version="1.0"?>
22
<!--
33
4-
Copyright 2016-2020 the original author or authors.
4+
Copyright 2016-2021 the original author or authors.
55
66
Licensed under the Apache License, Version 2.0 (the "License");
77
you may not use this file except in compliance with the License.
@@ -217,7 +217,7 @@
217217
<property name="target" value="CLASS_DEF, INTERFACE_DEF, ENUM_DEF, METHOD_DEF, CTOR_DEF, VARIABLE_DEF"/>
218218
</module>
219219
<module name="JavadocMethod">
220-
<property name="scope" value="public"/>
220+
<property name="accessModifiers" value="public"/>
221221
<property name="allowMissingParamTags" value="true"/>
222222
<property name="allowMissingReturnTag" value="true"/>
223223
<property name="allowedAnnotations" value="Override, Test"/>

‎pom.xml‎

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -39,7 +39,6 @@
3939
<clirr.comparisonVersion>1.2.0</clirr.comparisonVersion>
4040
<module.name>org.mybatis.dynamic.sql</module.name>
4141
<kotlin.version>1.5.0</kotlin.version>
42-
<jacoco.version>0.8.7</jacoco.version>
4342
<kotlin.compiler.jvmTarget>1.8</kotlin.compiler.jvmTarget>
4443
<sonar.sources>pom.xml,src/main/java,src/main/kotlin</sonar.sources>
4544
<sonar.tests>src/test/java,src/test/kotlin</sonar.tests>
Lines changed: 29 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,13 @@
11
# Complex Queries
2-
Enhancements in version 1.1.2 make it easier to code complex queries. The Select DSL is implemented as a set of related objects. As the select statement is built, intermediate objects of various types are returned from the various methods that implement the DSL. The select statement can be completed by calling the `build()` method many of the intermediate objects. Prior to version 1.1.2, it was necessary to call `build()` on the **last** intermediate object. This restriction has been removed, and it is now possible to call `build()` on **any** intermediate object. This, along with several other enhancements, has simplified the coding of complex queries.
2+
Enhancements in version 1.1.2 make it easier to code complex queries. The Select DSL is implemented as a set of related
3+
objects. As the select statement is built, intermediate objects of various types are returned from the various methods
4+
that implement the DSL. The select statement can be completed by calling the `build()` method many of the intermediate
5+
objects. Prior to version 1.1.2, it was necessary to call `build()` on the **last** intermediate object. This
6+
restriction has been removed, and it is now possible to call `build()` on **any** intermediate object. This, along with
7+
several other enhancements, has simplified the coding of complex queries.
38

4-
For example, suppose you want to code a complex search on a Person table. The search parameters are id, first name, and last name. The rules are:
9+
For example, suppose you want to code a complex search on a Person table. The search parameters are id, first name,
10+
and last name. The rules are:
511

612
1. If an id is entered, use the id and ignore the other search parameters
713
1. If an id is not entered, then do a fuzzy search based on the other parameters
@@ -19,15 +25,15 @@ public SelectStatementProvider search(Integer targetId, String fName, String lNa
1925
.and(id, isEqualTo(targetId));
2026
} else {
2127
builder
22-
.and(firstName, isLike(fName).when(Objects::nonNull).then(s -> "%" + s + "%")) // (4)
23-
.and(lastName, isLikeWhenPresent(lName).then(this::addWildcards)); // (5)
28+
.and(firstName, isLike(fName).filter(Objects::nonNull).map(s -> "%" + s + "%")) // (4) (5)
29+
.and(lastName, isLikeWhenPresent(lName).map(this::addWildcards)); // (6)
2430
}
2531

2632
builder
2733
.orderBy(lastName, firstName)
28-
.fetchFirst(50).rowsOnly(); // (6)
34+
.fetchFirst(50).rowsOnly(); // (7)
2935

30-
return builder.build().render(RenderingStrategies.MYBATIS3); // (7)
36+
return builder.build().render(RenderingStrategies.MYBATIS3); // (8)
3137
}
3238

3339
public String addWildcards(String s) {
@@ -37,11 +43,21 @@ public String addWildcards(String s) {
3743

3844
Notes:
3945

40-
1. Note the use of the `var` keyword here. If you are using an older version of Java, the actual type is `QueryExpressionDSL<SelectModel>.QueryExpressionWhereBuilder`
41-
1. Here we are calling `where()` with no parameters. This sets up the builder to accept conditions further along in the code. If no conditions are added, then the where clause will not be rendered
42-
1. This `if` statement implements the rules of the search. If an ID is entered , use it. Otherwise, do a fuzzy search based on first name and last name.
43-
1. The `then` statement on this line allows you to change the parameter value before it is placed in the parameter Map. In this case we are adding SQL wildcards to the start and end of the search String - but only if the search String is not null. If the search String is null, the lambda will not be called and the condition will not render
44-
1. This shows using a method reference instead of a lambda on the `then`. Method references allow you to more clearly express intent. Note also the use of the `isLikeWhenPresent` condition which is a built in condition that checks for nulls
45-
1. It is a good idea to limit the number of rows returned from a search. The library now supports `fetch first` syntax for limiting rows
46-
1. Note that we are calling the `build` method from the intermediate object retrieved in step 1. It is no longer necessary to call `build` on the last object returned from a select builder
46+
1. Note the use of the `var` keyword here. If you are using an older version of Java, the actual type is
47+
`QueryExpressionDSL<SelectModel>.QueryExpressionWhereBuilder`
48+
1. Here we are calling `where()` with no parameters. This sets up the builder to accept conditions further along in the
49+
code. If no conditions are added, then the where clause will not be rendered
50+
1. This `if` statement implements the rules of the search. If an ID is entered , use it. Otherwise, do a fuzzy search
51+
based on first name and last name.
52+
1. The `filter` method on this line will mark the condition as unrenderable if the filter is not satisfied.
53+
1. The `map` statement on this line allows you to change the parameter value before it is placed in the parameter Map.
54+
In this case we are adding SQL wildcards to the start and end of the search String - but only if the search String
55+
is not null. If the search String is null, the lambda will not be called and the condition will not render
56+
1. This line shows the use of a method reference instead of a lambda on the `map`. Method references allow you to more
57+
clearly express intent. Note also the use of the `isLikeWhenPresent` function which is a built-in function that
58+
applies a non-null filter
59+
1. It is a good idea to limit the number of rows returned from a search. The library now supports `fetch first` syntax
60+
for limiting rows
61+
1. Note that we are calling the `build` method from the intermediate object retrieved in step 1. It is no longer
62+
necessary to call `build` on the last object returned from a select builder
4763

‎src/site/markdown/docs/conditions.md‎

Lines changed: 72 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -33,9 +33,9 @@ Simple conditions are the most common - they render the basic SQL operators.
3333
| Null | where(foo, isNull()) | `where foo is null` |
3434

3535

36-
## Sub-Selects
36+
## Subqueries
3737

38-
Many conditions can be rendered with sub selects.
38+
Many conditions can be rendered with subqueries.
3939

4040
| Condition | Example | Result |
4141
|-----------|---------|--------|
@@ -62,6 +62,58 @@ Column comparison conditions can be used to write where clauses comparing the va
6262
| Less Than or Equals | where(foo, isLessThanOrEqualTo(bar)) | `where foo <= bar` |
6363
| Not Equals | where(foo, isNotEqualTo(bar)) | `where foo <> bar` |
6464

65+
## Value Transformation
66+
67+
All conditions (except `isNull` and `isNotNull`) support a `map` function that allows you to transform the value(s)
68+
associated with the condition before the statement is rendered. The map function functions similarly to the JDK
69+
standard `map` functions on Streams and Optionals - it allows you to transform a value and change the data type.
70+
71+
For example, suppose you want to code a wild card search with the SQL `like` operator. To make this work, you will
72+
need to append SQL wildcards to the search value. This can be accomplished directly i the condition with a `map`
73+
method as follows:
74+
75+
```java
76+
List<Animal> search(String searchName) {
77+
SelectStatementProvider selectStatement=select(id,animalName,bodyWeight,brainWeight)
78+
.from(animalData)
79+
.where(animalName,isLike(searchName).map(s->"%"+s+"%"))
80+
.orderBy(id)
81+
.build()
82+
.render(RenderingStrategies.MYBATIS3);
83+
84+
...
85+
}
86+
```
87+
88+
You can see the `map` method accepts a lambda that adds SQL wildcards to the `searchName` field. This is more succint
89+
if you use a method reference:
90+
91+
```java
92+
List<Animal> search(String searchName){
93+
SelectStatementProvider selectStatement=select(id,animalName,bodyWeight,brainWeight)
94+
.from(animalData)
95+
.where(animalName,isLike(searchName).map(this::appendWildCards))
96+
.orderBy(id)
97+
.build()
98+
.render(RenderingStrategies.MYBATIS3);
99+
}
100+
101+
String appendWildCards(String in) {
102+
return "%" + in + "%";
103+
}
104+
```
105+
106+
The `map` on each condition accepts a lambda expression that can be used to transform the value(s) associated with the
107+
condition. The lambda is the standard JDK type `Function&lt;T,R&gt;` where `T` is the type of the condition and `R`
108+
is the output type. For most conditions this should be fairly simple to understand. The unusual cases are detailed
109+
below:
110+
111+
1. The `Between` and `NotBetween` conditions have `map` methods that accept one or two map functions. If you pass
112+
one function, it will be applied to both values in the condition. If you supply two functions, then they will be
113+
applied to the first and second values respectively.
114+
1. The `In` and `NotIn` conditions accept a single mapping function and it will be applied to all values in the
115+
collection of values in the condition.
116+
65117
## Optional Conditions
66118

67119
All conditions support optionality - meaning they can be configured to render into the final SQL if a configured test
@@ -78,8 +130,8 @@ For example, you could code a search like this:
78130
SelectStatementProvider selectStatement = select(id, animalName, bodyWeight, brainWeight)
79131
.from(animalData)
80132
.where(animalName, isEqualTo(animalName_).filter(Objects::nonNull))
81-
.and(bodyWeight, isEqualToWhen(bodyWeight_).filter(Objects::nonNull))
82-
.and(brainWeight, isEqualToWhen(brainWeight_).filter(Objects::nonNull))
133+
.and(bodyWeight, isEqualTo(bodyWeight_).filter(Objects::nonNull))
134+
.and(brainWeight, isEqualTo(brainWeight_).filter(Objects::nonNull))
83135
.build()
84136
.render(RenderingStrategies.MYBATIS3);
85137
...
@@ -96,20 +148,22 @@ table lists the optional conditions and shows how to use them:
96148

97149
| Condition | Example | Rendering Rules |
98150
|-----------|---------|-----------------|
99-
| Between| where(foo, isBetween(x).and(y).when(BiPredicate)) | The library will pass x and y to the BiPredicate's test method. The condition will render if BiPredicate.test(x, y) returns true |
100-
| Equals | where(foo, isEqualTo(x).when(Predicate)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
101-
| Greater Than | where(id, isGreaterThan(x).when(Predicate)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
102-
| Greater Than or Equals | where(id, isGreaterThanOrEqualTo(x).when(Predicate)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
103-
| Less Than | where(id, isLessThan(x).when(Predicate)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
104-
| Less Than or Equals | where(id, isLessThanOrEqualTo(x).when(Predicate)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
105-
| Like | where(id, isLike(x).when(Predicate)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
106-
| Like Case Insensitive | where(id, isLikeCaseInsensitive(x).when(Predicate&lt;String&gt;)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
107-
| Not Between | where(id, isNotBetween(x).and(y).when(BiPredicate)) | The library will pass x and y to the BiPredicate's test method. The condition will render if BiPredicate.test(x, y) returns true |
108-
| Not Equals | where(id, isNotEqualTo(x).when(Predicate)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
109-
| Not Like | where(id, isNotLike(x).when(Predicate)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
110-
| Not Like Case Insensitive | where(id, isNotLikeCaseInsensitive(x).when(Predicate&lt;String&gt;)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
111-
| Not Null | where(id, isNotNull().when(BooleanSupplier) | The condition will render if BooleanSupplier.getAsBoolean() returns true |
112-
| Null | where(id, isNull().when(BooleanSupplier) | The condition will render if BooleanSupplier.getAsBoolean() returns true |
151+
| Between| where(foo, isBetween(x).and(y).filter(BiPredicate)) | The library will pass x and y to the BiPredicate's test method. The condition will render if BiPredicate.test(x, y) returns true |
152+
| Between| where(foo, isBetween(x).and(y).filter(Predicate)) | The library will invoke the Predicate's test method twice - once with x, once with y. The condition will render if both function calls return true |
153+
| Equals | where(foo, isEqualTo(x).filter(Predicate)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
154+
| Greater Than | where(id, isGreaterThan(x).filter(Predicate)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
155+
| Greater Than or Equals | where(id, isGreaterThanOrEqualTo(x).filter(Predicate)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
156+
| Less Than | where(id, isLessThan(x).filter(Predicate)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
157+
| Less Than or Equals | where(id, isLessThanOrEqualTo(x).filter(Predicate)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
158+
| Like | where(id, isLike(x).filter(Predicate)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
159+
| Like Case Insensitive | where(id, isLikeCaseInsensitive(x).filter(Predicate&lt;String&gt;)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
160+
| Not Between | where(id, isNotBetween(x).and(y).filter(BiPredicate)) | The library will pass x and y to the BiPredicate's test method. The condition will render if BiPredicate.test(x, y) returns true |
161+
| Not Between| where(foo, isNotBetween(x).and(y).filter(Predicate)) | The library will invoke the Predicate's test method twice - once with x, once with y. The condition will render if both function calls return true |
162+
| Not Equals | where(id, isNotEqualTo(x).filter(Predicate)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
163+
| Not Like | where(id, isNotLike(x).filter(Predicate)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
164+
| Not Like Case Insensitive | where(id, isNotLikeCaseInsensitive(x).filter(Predicate&lt;String&gt;)) | The library will pass x to the Predicate's test method. The condition will render if Predicate.test(x) returns true |
165+
| Not Null | where(id, isNotNull().filter(BooleanSupplier) | The condition will render if BooleanSupplier.getAsBoolean() returns true |
166+
| Null | where(id, isNull().filter(BooleanSupplier) | The condition will render if BooleanSupplier.getAsBoolean() returns true |
113167

114168
### "When Present" Condition Builders
115169
The library supplies several methods that supply conditions to be used in the common case of checking for null

‎src/site/markdown/docs/databaseObjects.md‎

Lines changed: 58 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -3,19 +3,23 @@ MyBatis Dynamic SQL works with Java objects that represent relational tables or
33

44
## Table or View Representation
55

6-
The class `org.mybatis.dynamic.sql.SqlTable` is used to represent a table or view in a database. An `SqlTable` holds a name, and a collection of `SqlColumn` objects that represent the columns in a table or view.
6+
The class `org.mybatis.dynamic.sql.SqlTable` is used to represent a table or view in a database. An `SqlTable` holds a
7+
name, and a collection of `SqlColumn` objects that represent the columns in a table or view.
78

89
A table or view name in SQL has three parts:
910

10-
1. The catalog - which is optional and is rarely used outside of Microsoft SQL Server. If unspecified the default catalog will be used - and many databases only have one catalog
11-
1. The schema - which is optional but is very often specified. If unspecified the default schema will be used
11+
1. The catalog - which is optional and is rarely used outside of Microsoft SQL Server. If unspecified the default
12+
catalog will be used - and many databases only have one catalog
13+
1. The schema - which is optional but is very often specified. If unspecified, the default schema will be used
1214
1. The table name - which is required
1315

1416
Typical examples of names are as follows:
1517

1618
- `"dbo..bar"` - a name with a catalog (dbo) and a table name (bar). This is typical for SQL Server
17-
- `"foo.bar"` - a name with a schema (foo) and a table name (bar). This is typical in many databases when you want to access tables that are not in the default schema
18-
- `"bar"` - a name with just a table name (bar). This will access a table or view in the default catalog and schema for a connection
19+
- `"foo.bar"` - a name with a schema (foo) and a table name (bar). This is typical in many databases when you want to
20+
access tables that are not in the default schema
21+
- `"bar"` - a name with just a table name (bar). This will access a table or view in the default catalog and schema for
22+
a connection
1923

2024
In MyBatis Dynamic SQL, the table or view name can be specified in different ways:
2125

@@ -46,9 +50,13 @@ public class MyTable extends SqlTable {
4650
```
4751

4852
### Dynamic Catalog and/or Schema Names
49-
MyBatis Dynamic SQL allows you to dynamically specify a catalog and/or schema. This is useful for applications where the schema may change for different users or environments, or if you are using different schemas to shard the database. Dynamic names are used when you use a `SqlTable` constructor that accepts one or more `java.util.function.Supplier` arguments.
53+
MyBatis Dynamic SQL allows you to dynamically specify a catalog and/or schema. This is useful for applications where
54+
the schema may change for different users or environments, or if you are using different schemas to shard the database.
55+
Dynamic names are used when you use a `SqlTable` constructor that accepts one or more `java.util.function.Supplier`
56+
arguments.
5057

51-
For example, suppose you wanted to change the schema based on the value of a system property. You could write a class like this:
58+
For example, suppose you wanted to change the schema based on the value of a system property. You could write a class
59+
like this:
5260

5361
```java
5462
public class SchemaSupplier {
@@ -60,7 +68,8 @@ public class SchemaSupplier {
6068
}
6169
```
6270

63-
This class has a static method `schemaPropertyReader` that will return an `Optional<String>` containing the value of a system property. You could then reference this method in the constructor of the `SqlTable` like this:
71+
This class has a static method `schemaPropertyReader` that will return an `Optional<String>` containing the value of a
72+
system property. You could then reference this method in the constructor of the `SqlTable` like this:
6473

6574
```java
6675
public static final class User extends SqlTable {
@@ -70,14 +79,18 @@ public static final class User extends SqlTable {
7079
}
7180
```
7281

73-
Whenever the table is referenced for rendering SQL, the name will be calculated based on the current value of the system property.
82+
Whenever the table is referenced for rendering SQL, the name will be calculated based on the current value of the
83+
system property.
7484

7585
There are two constructors that can be used for dynamic names:
7686

77-
1. A constructor that accepts `Supplier<Optional<String>>` for the schema, and `String` for the name. This constructor assumes that the catalog is always empty or not used
78-
1. A constructor that accepts `Supplier<Optional<String>>` for the catalog, `Supplier<Optional<String>>` for the schema, and `String` for the name
87+
1. A constructor that accepts `Supplier<Optional<String>>` for the schema, and `String` for the name. This constructor
88+
assumes that the catalog is always empty or not used
89+
1. A constructor that accepts `Supplier<Optional<String>>` for the catalog, `Supplier<Optional<String>>` for the schema,
90+
and `String` for the name
7991

80-
If you are using Microsoft SQL Server and want to use a dynamic catalog name and ignore the schema, then you should use the second constructor like this:
92+
If you are using Microsoft SQL Server and want to use a dynamic catalog name and ignore the schema, then you should use
93+
the second constructor like this:
8194

8295
```java
8396
public static final class User extends SqlTable {
@@ -98,11 +111,12 @@ Catalog Supplier Value | Schema Supplier Value | Name | Fully Qualified Name
98111

99112

100113
### Fully Dynamic Names
101-
MyBatis Dynamic SQL allows you to dynamically specify a full table name. This is useful for applications where the database is sharded with different tables representing different shards of the whole. Dynamic names are used when you use a `SqlTable` constructor that accepts a single `java.util.function.Supplier` argument.
102-
103-
Note that this functionality should only be used for tables that have different names, but are otherwise identical.
114+
MyBatis Dynamic SQL allows you to dynamically specify a full table name. This is useful for applications where the
115+
database is sharded with different tables representing different shards of the whole. Dynamic names are used when you
116+
use a `SqlTable` constructor that accepts a single `java.util.function.Supplier` argument.
104117

105-
For example, suppose you wanted to change the name based on the value of a system property. You could write a class like this:
118+
For example, suppose you wanted to change the name based on the value of a system property. You could write a class
119+
like this:
106120

107121
```java
108122
public class NameSupplier {
@@ -114,7 +128,8 @@ public class NameSupplier {
114128
}
115129
```
116130

117-
This class has a static method `namePropertyReader` that will return an `String` containing the value of a system property. You could then reference this method in the constructor of the `SqlTable` like this:
131+
This class has a static method `namePropertyReader` that will return an `String` containing the value of a system
132+
property. You could then reference this method in the constructor of the `SqlTable` like this:
118133

119134
```java
120135
public static final class User extends SqlTable {
@@ -126,23 +141,38 @@ public static final class User extends SqlTable {
126141

127142
Whenever the table is referenced for rendering SQL, the name will be calculated based on the current value of the system property.
128143

129-
130-
131144
## Column Representation
132145

133-
The class `org.mybatis.dynamic.sql.SqlColumn` is used to represent a column in a table or view. An `SqlColumn` is always associated with a `SqlTable`. In its most basic form, the `SqlColumn` class holds a name and a reference to the `SqlTable` it is associated with. The table reference is required so that table aliases can be applied to columns in the rendering phase.
146+
The class `org.mybatis.dynamic.sql.SqlColumn` is used to represent a column in a table or view. An `SqlColumn` is always
147+
associated with a `SqlTable`. In its most basic form, the `SqlColumn` class holds a name and a reference to the
148+
`SqlTable` it is associated with. The table reference is required so that table aliases can be applied to columns in the
149+
rendering phase.
134150

135-
The `SqlColumn` will be rendered in SQL based on the `RenderingStrategy` applied to the SQL statement. Typically the rendering strategy generates a string that represents a parameter marker in whatever SQL engine you are using. For example, MyBatis3 parameter markers are formatted as "#{some_attribute}". By default, all columns are rendered with the same strategy. The library supplies rendering strategies that are appropriate for several SQL execution engines including MyBatis3 and Spring JDBC template.
151+
The `SqlColumn` will be rendered in SQL based on the `RenderingStrategy` applied to the SQL statement. Typically the
152+
rendering strategy generates a string that represents a parameter marker in whatever SQL engine you are using. For
153+
example, MyBatis3 parameter markers are formatted as "#{some_attribute}". By default, all columns are rendered with the
154+
same strategy. The library supplies rendering strategies that are appropriate for several SQL execution engines
155+
including MyBatis3 and Spring JDBC template.
136156

137-
In some cases it is necessary to override the rendering strategy for a particular column - so the `SqlColumn` class supports specifying a rendering strategy for a column that will override the rendering strategy applied to a statement. A good example of this use case is with PostgreSQL. In that database it is required to add the string "::jsonb" to a prepared statement parameter marker when inserting or updating JSON fields, but not for other fields. A column based rendering strategy enables this.
157+
In some cases it is necessary to override the rendering strategy for a particular column - so the `SqlColumn` class
158+
supports specifying a rendering strategy for a column that will override the rendering strategy applied to a statement.
159+
A good example of this use case is with PostgreSQL. In that database it is required to add the string "::jsonb" to a
160+
prepared statement parameter marker when inserting or updating JSON fields, but not for other fields. A column based
161+
rendering strategy enables this.
138162

139-
The `SqlColumn` class has additional optional attributes that are useful for SQL rendering - especially in MyBatis3. These include:
163+
The `SqlColumn` class has additional optional attributes that are useful for SQL rendering - especially in MyBatis3.
164+
These include:
140165

141-
* The `java.sql.JDBCType` of the column. This will be rendered into the MyBatis3 compatible parameter marker - which helps with picking type handlers and also inserting or updating null capable fields
142-
* A String containing a type handler - either a type handler alias or the fully qualified type of a type handler. This will be rendered into the MyBatis3 compatible parameter marker
166+
* The `java.sql.JDBCType` of the column. This will be rendered into the MyBatis3 compatible parameter marker - which
167+
helps with picking type handlers and also inserting or updating null capable fields
168+
* A String containing a type handler - either a type handler alias or the fully qualified type of a type handler. This
169+
will be rendered into the MyBatis3 compatible parameter marker
143170

144-
If you are not using MyBatis3, then you will not need to specify the JDBC Type or type handler as those attributes are ignored by other rendering strategies.
171+
If you are not using MyBatis3, then you do not need to specify the JDBC Type or type handler as those attributes are
172+
ignored by other rendering strategies.
145173

146-
Finally, the `SqlColumn` class has methods to designate a column alias or sort order for use in different SQL statements.
174+
Finally, the `SqlColumn` class has methods to designate a column alias or sort order for use in different SQL
175+
statements.
147176

148-
We recommend a usage pattern for creating table and column objects that provides quite a bit of flexibility for usage. See the [Quick Start](quickStart.html) page for a complete example.
177+
We recommend a usage pattern for creating table and column objects that provides quite a bit of flexibility for usage.
178+
See the [Quick Start](quickStart.html) page for a complete example.

‎src/site/markdown/docs/delete.md‎

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -37,7 +37,8 @@ import org.mybatis.dynamic.sql.util.SqlProviderAdapter;
3737

3838
## XML Mapper for Delete Statements
3939

40-
We do not recommend using an XML mapper for delete statements, but if you want to do so the DeleteStatementProvider object can be used as a parameter to a MyBatis mapper method directly.
40+
We do not recommend using an XML mapper for delete statements, but if you want to do so, the DeleteStatementProvider
41+
object can be used as a parameter to a MyBatis mapper method directly.
4142

4243
If you are using an XML mapper, the delete method should look like this in the Java interface:
4344

‎src/site/markdown/docs/introduction.md‎

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -13,16 +13,16 @@ parameters required for that statement. The SQL statement object can be used di
1313

1414
The library will generate these types of SQL statements:
1515

16+
- COUNT statements - specialized SELECT statements that return a Long value
1617
- DELETE statements with flexible WHERE clauses
1718
- INSERT statements of several types:
18-
- A statement that inserts a single record and will insert null values into columns (a "full" insert)
19-
- A statement that inserts a single record that will ignore null input values and their associated columns (a "selective" insert)
19+
- A statement that inserts a single row with values supplied from a corresponding Object
20+
- A statement that inserts a single row with values supplied directly in the statement
21+
- A statement that inserts multiple rows using multiple VALUES clauses
22+
- A statement that inserts multiple rows using a JDBC batch
2023
- A statement that inserts into a table using the results of a SELECT statement
21-
- A parameter object is designed for inserting multiple objects with a JDBC batch
2224
- SELECT statements with a flexible column list, a flexible WHERE clause, and support for distinct, "group by", joins, unions, "order by", etc.
23-
- UPDATE statements with a flexible WHERE clause. Like the INSERT statement, there are two varieties of UPDATE statements:
24-
- A "full" update that will set null values
25-
- A "selective" update that will ignore null input values
25+
- UPDATE statements with a flexible WHERE clause, and flexible SET clauses
2626

2727
The primary goals of the library are:
2828

0 commit comments

Comments
 (0)
Please sign in to comment.