MyBatis version

3.4.1-SNAPSHOT/master

Test case or example project

o.a.i.submitted.overload.OverloadTest - See pull request #704 for the testcase and more details.

Steps to reproduce

Given - a mapper interface with two methods with the same name but different parameter sets (e.g. one and two parameters) - a mapper xml with a single statement with the same name as the interface method, using all parameters from the interface, but properly checking for null values ## Expected result One can use both methods, both being properly mapped to the sql statement from the mapper xml ## Actual result Trying to execute the method not having all parameters used in the mapper xml statement will result in a BindingException

Comment From: harawata

This has been asked several times before, but it is labeled as "won't fix". https://github.com/mybatis/old-google-code-issues/issues/231

Basically, we couldn't find a simple way to differentiate those statements. When you want to use one of the overloaded methods as a nested select, for example, what would the statement ID look like?

Comment From: harawata

This still is "won't fix" until someone came up with an elegant solution.

Comment From: dongyado

so there are two ways to handle variable parameter method overload: 　 1. use Map parameter 2. use different method name

Comment From: grantsunny

Met this issue and google lead me here. My2Cents. one could leverage one optional Id attribute as part of @Select annotation, to explicitly supply one Id to the method and the framework can notify the user to use this annotation when there is duplication observed, during startup. This de-couples the method name and id. Cannot this be more graceful than restrict the language feature by a given framework.

@Select("SELECT * FROM student", id="selectAllFromStudent") List loadStudents();

@Select("SELECT * FROM student WHERE name = #{name}" id="selectStudentsByName") List loadStudents(String name);

Comment From: harawata

Thank you for the input @grantsunny ,

There is an open PR #1519 which basically is the same idea as yours and some people seem to like it.

However, I am still not convinced if it's worth supporting overloaded methods. I think the result is simpler/better if you simply rename the method(s).

In your case, for example, if you name the second method loadStudentsByName(String), you don't lose much and it's easier for future readers to understand the code, especially if the statement is referenced from result maps as a nested select.

Anyway, please upvote #1519 if you like it. We might merge it if it gets many upvotes.

Comment From: grantsunny

Thank you @harawata - I will be there and upvote it. I agree renaming a method does not lose much though, as getXXXById, getXXXByType. It works in principle but I think the upvoters just feel hesitated to loose the flexibility. In my opinion, fr the code readers, having explicitly annotated id will be easier to understood than assuming the id the same with method name which is not that obvious, right? Have a nice day!