Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add @StatementId to support overloaded mapper methods #1519

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

harawata
Copy link
Member

This PR introduces a new annotation @StatementId to let users assign arbitrary statement ID [1].

@StatementId("selectAll")
@Select("select * from users")
List<User> select();

@StatementId("selectById")
User select(Integer id);

When the value is omitted, MyBatis will calculate the ID from the method signature.
e.g.

@StatementId // -> select#User
User select(User user);

@StatementId // -> select#String[]_Date
User select(String[] names, Date dateOfBirth);

There is no documentation yet.
I haven't decided if this should be merged or not and there could be changes in the spec.
Should fix #1482 . Related to #1312 .

Any feedback is appreciated! 馃檹

[1] I plan to apply more strict validation to the user-specified ID. e.g. valid characters are alphanumeric, underscore, brackets [] and pound sign #.

@heshengbang
Copy link

heshengbang commented Jul 3, 2019

This is a great idea, the error message like 'invlid bound statement(not found):' will not occur often.

# Conflicts:
#	src/main/java/org/apache/ibatis/builder/annotation/MapperAnnotationBuilder.java
@coveralls
Copy link

Coverage Status

Coverage increased (+0.03%) to 87.276% when pulling 0fae53f on harawata:gh/1482-overloaded-methods into 717bba5 on mybatis:master.

@grantsunny
Copy link

grantsunny commented Mar 19, 2024

+1. Having explicit assigned id will bring more consistence between XML and annotation based configuration, avoiding the shortcoming on usage of convention. By the way I assume even without @StatementiD it is still a good idea to have the framework still generate the internal statementId according the method name plus signature when there is overloading happens, and notify the programmer during framework startup, instead of raise error like today's framework. For backward compatible in a non-overloaded case, we can keep the id as simple as the method name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support overloaded methods mapped to individual statements
4 participants