Available as of Camel 2.7
The mybatis: component allows you to query, poll, insert, update and delete data in a relational database using MyBatis.
Maven users will need to add the following dependency to their pom.xml for this component:
Where statementName is the statement name in the MyBatis XML mapping file which maps to the query, insert, update or delete operation you wish to evaluate.
You can append query options to the URI in the following format, ?option=value&option=value&...
This component will by default load the MyBatis SqlMapConfig file from the root of the classpath with the expected name of SqlMapConfig.xml.
Camel will populate the result message, either IN or OUT with a header with the statement used:
The response from MyBatis will only be set as the body if it's a SELECT statement. That means, for example, for INSERT statements Camel will not replace the body. This allows you to continue routing and keep the original body. The response from MyBatis is always stored in the header with the key CamelMyBatisResult.
For example if you wish to consume beans from a JMS queue and insert them into a database you could do the following:
Notice we have to specify the statementType, as we need to instruct Camel which kind of operation to invoke.
Where insertAccount is the MyBatis ID in the SQL mapping file:
When routing to an MyBatis endpoint you will want more fine grained control so you can control whether the SQL statement to be executed is a SELECT, UPDATE, DELETE or INSERT etc. So for instance if we want to route to an MyBatis endpoint in which the IN body contains parameters to a SELECT statement we can do:
In the code above we can invoke the MyBatis statement selectAccountById and the IN body should contain the account id we want to retrieve, such as an Integer type.
We can do the same for some of the other operations, such as SelectList:
And the same for UPDATE, where we can send an Account object as the IN body to MyBatis:
Available as of Camel 2.10
MyBatis allows you to insert multiple rows using its for-each batch driver. To use this, you need to use the <foreach> in the mapper XML file. For example as shown below:
Then you can insert multiple rows, by sending a Camel message to the mybatis endpoint which uses the InsertList statement type, as shown below:
Available as of Camel 2.11
MyBatis allows you to update multiple rows using its for-each batch driver. To use this, you need to use the <foreach> in the mapper XML file. For example as shown below:
Then you can update multiple rows, by sending a Camel message to the mybatis endpoint which uses the UpdateList statement type, as shown below:
Available as of Camel 2.11
MyBatis allows you to delete multiple rows using its for-each batch driver. To use this, you need to use the <foreach> in the mapper XML file. For example as shown below:
Then you can delete multiple rows, by sending a Camel message to the mybatis endpoint which uses the DeleteList statement type, as shown below:
Parameter of any type (List, Map, etc.) can be passed to mybatis and an end user is responsible for handling it as required
In the sample below we poll the database, every 30 seconds using the Timer component and send the data to the JMS queue:
And the MyBatis SQL mapping file used:
This component supports executing statements after data have been consumed and processed by Camel. This allows you to do post updates in the database. Notice all statements must be UPDATE statements. Camel supports executing multiple statements whose names should be separated by commas.
The route below illustrates we execute the consumeAccount statement data is processed. This allows us to change the status of the row in the database to processed, so we avoid consuming it twice or more.
And the statements in the sqlmap file:
Setting up a transaction manager under camel-mybatis can be a little bit fiddly, as it involves externalising the database configuration outside the standard MyBatis SqlMapConfig.xml file.
The first part requires the setup of a DataSource. This is typically a pool (either DBCP, or c3p0), which needs to be wrapped in a Spring proxy. This proxy enables non-Spring use of the DataSource to participate in Spring transactions (the MyBatis SqlSessionFactory does just this).
This has the additional benefit of enabling the database configuration to be externalised using property placeholders.
A transaction manager is then configured to manage the outermost DataSource:
The camel-mybatis component is then configured with that factory:
Finally, a transaction policy is defined over the top of the transaction manager, which can then be used as usual: