Provide a naming strategy for Mybatis method/statement names. [DATAJDBC-418]

[spring-projects-issues]

Tyler K Van Gorder opened DATAJDBC-418 and commented

In our traditional Mybatis applications, we had a common pattern where our DataAcccess objects were co-located with our Mapper Interfaces & any associated Mapper.xml files: 

As an example, if "AttributeDefinition" is the aggregate root:

com.example.model.attribute:
  AttributeDefinition
  UnitOfMeasure
  AttributeDefinitionEnumeratedValue

And the data access for all three of those domain types ends up looking like this: 

 

com.example.dao.attribute: 

  AttributeDefinitionDao.java
  AttributeDefinitionDaoImpl.java
  AttributeDefinitionMapper.java
  AttributeDefinitionMapper.xml

And the mapper has queries for the aggregate root AND its associated domain types.

 

I am prototyping some work with Spring Data JDBC + Mybatis and I would like to group the mappers with the repository that is ultimately going to be using those mappers:

com.example.dao.attribute

  AttributeDefinitionRepository.java
  AttributeDefinitionMapper.java
  AttributeDefinitionMapper.xml
  

Where the queries for all domain types connected to the aggregate root are in the same mapper. 

I can use the NamespaceStrategy to map a domain type into the correct namespace, however, the statements are hard-coded and assume each domain type is mapped one-to-one with a corresponding mapper. 

Can we expand the NamespaceStrategy such that it can be passed both the domain type AND the method name?

Another really nice feature would be to have an out-of-the-box configuration strategy (annotation-based or Spring environment-based) that can be used to map a domain type to a Mybatis mapper namespace.

 

---

Affects: 1.1 RC3 (Moore)

[spring-projects-issues]

Tyler K Van Gorder commented

More information on this:

The mybatis generator typically promotes a "flat" structure for all types/mappers and it promotes putting the generated types in a different package from the mapper interfaces. It is straightforward to use a custom NamspaceStrategy to accommodate this use case.

However, this flat structure can be problematic when you have 400+ entities and the natural thing to do in code is to organize things via sub-packages. The mapping of types -> mapper namespace can still be implemented via ConfigurationProperties, but it would require all 400+ entities to be enumerated in a property source. 

I have been prototyping an annotation-based approach using my own MybatisDataAccessStrategy, I am not sure if this is something that should be integrated with the core project or just something we maintain separate, as it may be overly opinionated. 8) I can put together a pull request if there is interest. 

 

My approach was to add a new AggregateMapper annotation and this ends up looking like this:

@Mapper
@AggregateMapper({AttributeDefinition.class, AttributeDefinitionValue.class})
public interface AttributeDefinitionMapper extends Serializable {


	AttributeDefinition findByIdAttributeDefinition(@Param("id") Integer id);
}

This essentially is saying AttributeDefinitionMapper is managing MybatisStatements for the ArributeDefinition and AttributeDefinitionValue domain types.

When constructing the MybatisDataAccessStrategy, I find all beans that have the AggregateMapper annotation and then build up a map of the domain types -> mapper namespace. 

The second change I made was to add a method to NamespaceStrategy, given a domain type and a db action, the namespace strategy spits back the fully qualified statement. This allows for more than one domain type to be hosted in a single mapper: 

@Override
public String getStatementName(Class<?> domainType, String relativeMethodName) {
     String namespace = mybatisNamespaceMap.get(domainType);
     if (namespace == null) {
          return domainType.getName() + "Mapper." + relativeMethodName;
     } else {
          return namespace + "." + relativeMethodName + domainType.getSimpleName();
     }
}

This may be too far out in the weeds to add to the core project, but regardless I thought I would share one way to solve this sort of mapping exercise.