Mybatis Generator: What's the best way to separate out "auto generated" and "hand edited files"

Question

I am on a project that uses both Mybatis (for persisting java to database) and Mybatis Generator (to automatically generate the mapper xml files and java interfaces from a database schema).

Mybatis generator does a good job at generating the files necessary for basic crud operation.

Context

For some of the tables/classes, we will need more "stuff" (code queries, etc) than the "crud stuff" generated by the MyBatis Generator tool.

Is there any way to have "best of both worlds", i.e use auto generation as as well as "custom code". How do you separate out and structure the "hand edited files" and "automatically generated files".

Proposal

I was thinking about the following, i.e. for table "Foo"

Auto-Generated

• FooCrudMapper.xml
• interface FooCrud.java

(where "Crud" stands for "Create Read Update Delete")

Hand Edited

• FooMapper.xml
• interface Foo extends FooCrud

The notion: if the schema changed, you could always safely autogenerate the "Crud" xml and .java files without wiping out any of the custom changes.

Questions

• Would mybatis correctly handle this scenario, i.e. would this mapper correctly execute the auto-generated 'crud code'?

  FooMapper fooMapper = sqlSession.getMapper(FooMapper.class);

• What approach do you recommend?

Edit 1: * Our db design uses a 'core table' ("element") with other tables 'extending' that table and adding extra attributes (shared key) . I've looked at docs and source concluded that I cannot use Mybatis Generator in conjunction with such 'extension' without any hand editing:

i.e. This does not work. -ElementMapper extends "ElementCrudMapper" -FooMapper.xml extends both "ElementCrudMapper" and "FooCrudMapper"

thanks all!

Answer 1

I can seperate out generated files and hand edited files.

I use mybatis-spring and spring to manage dao interfaces. This library allows MyBatis to participate in Spring transactions, takes care of building MyBatis mappers and SqlSessions and inject them into other beans, translates MyBatis exceptions into Spring DataAccessExceptions, and finally, it lets you build your application code free of dependencies on MyBatis, Spring or MyBatis-Spring.

For DAO Interfaces, I write a generic MybatisBaseDao to represent base interface generated by mybatis generator.

    public interface MybatisBaseDao<T, PK extends Serializable, E> {
    int countByExample(E example);

    int deleteByExample(E example);

    int deleteByPrimaryKey(PK id);

    int insert(T record);

    int insertSelective(T record);

    List<T> selectByExample(E example);

    T selectByPrimaryKey(PK id);

    int updateByExampleSelective(@Param("record") T record, @Param("example") E example);

    int updateByExample(@Param("record") T record, @Param("example") E example);

    int updateByPrimaryKeySelective(T record);

    int updateByPrimaryKey(T record);
    }

Of course, you can custom your BaseDao according to your demand. For example we have a UserDao, Then you can defind it like this

public interface UserDao extends MybatisBaseDao<User, Integer, UserExample>{
    List<User> selectUserByAddress(String address); // hand edited query method
}

For mapper xml files, I create two packages in mapper(.xml) base folder to separate generated files and hand edited files. For UserDao above, I put UserMapper.xml generated by generator in package named 'generated'. I put all hand writing mapper sqls into another UserMapper.xml file in the package named manual. The two mapper files start with the same header <mapper namespace="com.xxx.dao.UserDao" >. Mybatis can scan the xml mapper files to map sql and corresponding interface method automatically.

For generated entities and example objects I overwrite them directly.

I hope the method above can help you!