Reduce @Results boilerplate using DynamicSqlSupport classes
Closed this issue · 5 comments
Related to the previous discussion in #964.
It would be useful if the generated @results could be directly associated with the SqlTable in the corresponding DynamicSqlSupport class.
This would allow ResultMap to be automatically generated from the support class, reducing redundancy and ensuring consistency.
It would be useful to have an enhancement like:
@Results(id="CategoryResult", support=CategoryDynamicSqlSupport.Category.class)
or
@AutoResults(CategoryDynamicSqlSupport.Category.class)
so that the framework can automatically build the ResultMap based on the existing column definitions, reducing redundancy and avoiding inconsistency.
This would take a change to MyBatis itself, not just the dynamic SQL project. There have been many requests and proposals for such a feature over the years...here are a few:
mybatis/mybatis-3#91
mybatis/mybatis-3#157
mybatis/mybatis-3#1612
mybatis/mybatis-3#1613
mybatis/mybatis-3#1635
In general, I think the team is favorable to doing something in this space, but it is very complex and there are many corner cases. So I can't say whether this will get implemented anytime soon.
For your particular idea - using the support class to build a result map - the problem is that MyBatis doesn't have a mechanism for injecting a resultMap into the result processing. Implementing something like a dynamic result mapping could be an incremental step towards this idea, but again it would take a change in the core project.
Thank you for the detailed explanation!
I’ve seen that some of the related issues suggest using annotations on the entity classes to solve this, but personally I feel that approach is rather intrusive and not ideal.
What I had in mind was whether there could be some mechanism to align with resultMap (or convert to it) more naturally.
Since the generated SqlTable already provides convenient access to all columns, it seems like it should be a good foundation for bridging or transforming into a resultMap.
Do you think such an incremental mechanism might be feasible as a way forward?
Currently, SqlTable does not provide a built-in way to retrieve all associated SqlColumns programmatically.
If there were such a mechanism, it would make it much easier to transform a SqlTable into a resultMap automatically.
I think an incremental step forward would first be to enable MyBatis to accept a dynamic result map. How that map gets built is secondary in my mind.
I don't think retrieving a list of column objects from the table is necessary. It would be far more interesting to retrieve a list of columns from the select statement and transform it to a result map. Then this mechanism could work for joins, ad-hoc queries, etc.
For the case of single table results mapped to a known object (like the code the generator produces), in many cases MyBatis can already automap the results without an explicit result map. The generator creates verbose code because we support declarations of type handlers and other refinements to the result map in the generator - and it is generated code so it needs to work in a lot of circumstances.
If you would like to help with this, the place to start is in MyBatis itself. If MyBatis could support a dynamic result map, then we would have a lot of interesting possibilities.
You're right, thank you for the clarification!