Merge pull request #4 from bwajtr/fb-mybatis

Implementation for MyBatis

Author: Břetislav Wajtr

README.md

@@ -1,17 +1,23 @@
 # Java repository layer frameworks comparison
 
-Comparison of usage of non-JPA SQL mapping (persistence) frameworks for Java (Jooq, Spring JDBCTemplate etc.).
+Comparison of usage of non-JPA SQL mapping (persistence) frameworks for Java (Jooq, Spring JDBCTemplate, MyBatis etc.).
 
-We are not comparing performance (that'll be maybe added later), but rather how are these frameworks used for everyday tasks.
+We are not comparing performance, but rather how are these frameworks used for everyday tasks.
 
-We prepared some common scenarios, which you typically need to implement data-centric application, and then we implemented these scenarios using various non-JPA DB layer frameworks.
+We prepared some common scenarios, which you typically need to implement data-centric application, and then we implemented these scenarios using various non-JPA DB layer frameworks. This project should serve
+- as point of reference when deciding for SQL mapping framework 
+- as a template of common framework usage scenarios (see scenarios below)
+- to document best practices of such common usages (**comments are welcomed!**)
+
+**Use code in the repository as you like (MIT License)**
 
 ## Frameworks compared
 
 * Spring JDBCTemplate (see [implementation](src/main/java/com/clevergang/dbtests/repository/impl/jdbctemplate/JDBCDataRepositoryImpl.java))
 * jOOQ (see [implementation](src/main/java/com/clevergang/dbtests/repository/impl/jooq/JooqDataRepositoryImpl.java))
+* MyBatis (see [implementation](src/main/java/com/clevergang/dbtests/repository/impl/mybatis/MyBatisDataRepositoryImpl.java) and  [mapper](src/main/resources/mybatis/mappers/DataRepositoryMapper.xml))
 
-We tried to find optimal (== most readable) implementation in every framework, but comments are welcomed! There are lot of comments explaining why we chose to such implementation and some FIXMEs on places which we do not like, but which cannot be implemented differently or which we do not know how to improve...
+We tried to find optimal (== most readable) implementation in every framework, but comments are welcomed! There are lot of comments explaining why we chose to such implementation and some FIXMEs on places which we do not like, but which cannot be implemented differently or which we have troubles to improve...
 
 ## Scenarios implemented
 
@@ -49,11 +55,47 @@ Well, we were trying to "stick with standard" in our projects so we used JPA in
 
 So we dropped JPA completely, started using JDBCTemplate and discovered that we can deliver apps sooner (which was kind of surprising), they are a lot faster (thanks to effective use of DB) and much more robust... This was really relaxing and we do not plan to return to JPA at all... (yes, even for CRUD applications!) 
 
-This project aims to explore other options in the SQL mapping area than just JDBCTemplate. It should serve us
- 
-- as point of reference when deciding for SQL mapping framework 
-- as a template of common DB usage scenarios
-- to document best practices of such common usages (**comments are welcomed!**)
-
-
-**Use code in the repository as you like (MIT License)**
+This project aims to explore other options in the SQL mapping area than just JDBCTemplate. 
+
+## Conclusions/Notes
+
+I was able to implement all of the scenarios with all of the tested frameworks -
+with only difference in how comfortable or inconvenient it was. Please note that following remarks 
+are very subjective and does not have to necessarily apply to you.
+
+#### What would I choose
+  
+1. If project manager is ok with additional cost of a licence or the project uses one of open source databases (like PostgreSQL) then definitely go with **jOOQ**.
+2. If project uses Oracle, DB2, MSSQL or any other commercial database and additional cost for jOOQ licence is not acceptable, then go with **JDBCTemplate** 
+  
+#### Subjective pros/cons of each framework 
+
+**JDBC Template**
+* Pros
+    * Feels like you are very close to JDBC itself
+    * Implemented all of the scenarios without bigger issues - there were no hidden surprises
+    * Very easy batch operations
+    * Easy setup
+* Cons
+    * Methods in JDBCDataRepositoryImpl are not much readable - that's because you have to inline SQL in Java code. It would have been better if Java supported multiline strings.
+    * Debug logging could be better  
+
+**jOOQ**
+* Pros
+  * Very fluent, very easy to write new queries, code is very readable
+  * Once setup it's very easy to use, excellent for simple queries
+  * Awesome logger debug output
+* Cons
+  * Paid licence for certain databases - it'll be difficult to persuade managers that it's worth it :)
+  * Not so much usable for big queries - it's better to use native SQL (see scenario 9.)
+  * Weird syntax for performing batch operations (in case that you do not use UpdatableRecord). But it's not a big deal... 
+  
+
+**MyBatis**
+* Pros
+  * Writing SQL statements in XML mapper file feels good - it's easy to work with parameters.
+* Cons
+  * quite a lot of files for single DAO imlementation (MyBatisDataRepositoryImpl, DataRepositoryMapper and DataRepositoryMapper.xml), though navigation is not such a big deal
+  * at version 3.4.0 unable to work with Java8 DateTime types (LocalDate etc.), support possible through 3rd party library (mybatis-types), see build.gradle and <typeHandlers> configuration in mybatis-config.xml
+  * can't run batch and non-batch operations in single SqlSession, but have to create completely new SqlSession instead (see configuration in DbTestsApplication class). Surprisingly, this does not necessarily mean that the batch and non-batch operations will be executed in different transactions (as we would expect), so at the end this is not a total drawback, but just inconvenience
+  * expected that localCacheScope=STATEMENT is default MyBatis behavior, which is not... I know this is questionable drawback, but it was kind of surprise for me, see mybatis-config.xml

build.gradle

@@ -17,6 +17,7 @@ description = 'Comparison and common patterns for non-JPA SQL mapping frameworks
 
 repositories {
     jcenter()
+    maven { url "https://jitpack.io" }
 }
 
 // We need Java8 for this project
@@ -27,10 +28,14 @@ tasks.withType(JavaCompile) {
 dependencies {
     compile "org.springframework.boot:spring-boot-starter-jdbc"
     compile "org.springframework.boot:spring-boot-starter-jooq"
+    compile 'org.mybatis.spring.boot:mybatis-spring-boot-starter:1.1.1'
     compile "org.postgresql:postgresql:9.4.1211.jre7"
     compile "org.apache.commons:commons-lang3:3.4"
     compile "org.apache.commons:commons-collections4:4.1"
 
+    // required so mybatis works with java8 datetime classes (LocalDate)
+    compile 'com.github.javaplugs:mybatis-types:0.3'
+
     testCompile "org.springframework.boot:spring-boot-starter-test"
 }
 

sql-updates/create-script.sql

@@ -18,13 +18,13 @@ CREATE TABLE Company (
 
 CREATE TABLE Department (
   pid SERIAL PRIMARY KEY,
-  company_pid INTEGER NOT NULL REFERENCES Company (pid) ON DELETE CASCADE,
+  company_pid INTEGER NOT NULL REFERENCES Company (pid) ON DELETE NO ACTION,
   name TEXT NOT NULL
 );
 
 CREATE TABLE Employee (
   pid            SERIAL PRIMARY KEY,
-  department_pid INTEGER NOT NULL REFERENCES Department (pid) ON DELETE CASCADE,
+  department_pid INTEGER NOT NULL REFERENCES Department (pid) ON DELETE NO ACTION,
   name           TEXT    NOT NULL,
   surname        TEXT    NOT NULL,
   email          TEXT,
@@ -40,8 +40,8 @@ CREATE TABLE Project (
 );
 
 CREATE TABLE ProjectEmployee (
-  project_pid INTEGER REFERENCES Project,
-  employee_pid INTEGER REFERENCES Employee,
+  project_pid INTEGER REFERENCES Project ON DELETE NO ACTION,
+  employee_pid INTEGER REFERENCES Employee ON DELETE NO ACTION,
   PRIMARY KEY (project_pid, employee_pid)
 );
 

src/main/java/com/clevergang/dbtests/DbTestsApplication.java

@@ -1,14 +1,22 @@
 package com.clevergang.dbtests;
 
+import org.apache.ibatis.session.ExecutorType;
+import org.apache.ibatis.session.SqlSession;
+import org.apache.ibatis.session.SqlSessionFactory;
 import org.jooq.conf.RenderNameStyle;
 import org.jooq.conf.Settings;
 import org.jooq.conf.StatementType;
+import org.mybatis.spring.SqlSessionFactoryBean;
+import org.mybatis.spring.SqlSessionTemplate;
 import org.springframework.beans.factory.annotation.Qualifier;
 import org.springframework.boot.SpringApplication;
 import org.springframework.boot.autoconfigure.SpringBootApplication;
 import org.springframework.context.annotation.Bean;
 import org.springframework.context.annotation.Configuration;
 import org.springframework.context.annotation.Primary;
+import org.springframework.core.io.ClassPathResource;
+
+import javax.sql.DataSource;
 
 /**
  * This whole thing is based on Spring Boot as we plan to use these frameworks with SpringBoot
@@ -17,6 +25,10 @@
 @Configuration
 public class DbTestsApplication {
 
+    /**
+     * JOOQ CONFIGURATIONS
+     **/
+
     @Bean
     @Primary
     public Settings jooqSettings() {
@@ -35,6 +47,37 @@ public Settings jooqStaticStatementSettings() {
         return ret;
     }
 
+    /**
+     * MYBATIS CONFIGURATIONS
+     **/
+
+    @Bean
+    @Primary
+    @SuppressWarnings("SpringJavaAutowiringInspection")
+    public SqlSession myBatisDefaultSession(SqlSessionFactory sqlSessionFactory) {
+        return new SqlSessionTemplate(sqlSessionFactory);
+    }
+
+    @Bean
+    @Qualifier("batch-operations")
+    @SuppressWarnings("SpringJavaAutowiringInspection")
+    public SqlSession myBatisBatchOperationstSession(DataSource dataSource) throws Exception {
+        /*
+            NOTE: Unfortunately, in MyBatis it's not possible to execute batch and non-batch operations in single SqlSession.
+            To support this scenario, we have to create completely new SqlSessionFactoryBean and completely new
+            SqlSession. Surprisingly, this does not necessarily mean that the batch and non-batch operations will be
+            executed in different transactions (as we would expect) - we tested this configuration using scenario 8.
+            and it turned out that the bot non-batch and batch operations were run using same connection and in same transaction.
+            I guess this has something to do with how connection is obtained by MyBatis from dataSource...
+        */
+
+        SqlSessionFactoryBean sqlSessionFactoryBean = new SqlSessionFactoryBean();
+        sqlSessionFactoryBean.setDataSource(dataSource);
+        sqlSessionFactoryBean.setConfigLocation(new ClassPathResource("mybatis/mybatis-config.xml"));
+
+        return new SqlSessionTemplate(sqlSessionFactoryBean.getObject(), ExecutorType.BATCH);
+    }
+
     public static void main(String[] args) {
         SpringApplication.run(DbTestsApplication.class, args);
     }