Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
PR showing resultMap Bug when SQL using "as" aliases for column names #1100
This PR is intended to show a bug that was introduced with mybatis 3.4.3.
I've added a couple of tests in org.apache.ibatis.submitted.automapping.AutomappingTest (shouldGetAUserWithoutAsAliases and shouldGetAUserWithAsAliases) that show the issue. The tests are the same, but the second fails using a SQL statement that include an "as" alias.
This test would have worked with mybatis 3.4.2 and earlier.
I'm not 100% sure, but I think the issue was introduced with #895.
Note: this PR is expected to fail the build because it includes tests that expose what is believed to be a bug (see #1101).
referenced this pull request
Sep 19, 2017
Hi @dankirkd ,
Thank you for the test case.
And the result map is declared as follows.
<resultMap type="issue1101.User" id="result2"> <id property="id" column="id"/> <result property="name" column="name"/> <result property="phone" column="phone_number"/> </resultMap>
There is no
I am very surprised to hear that with 3.4.2 this test failed.
We have a similar setup with the problem:
With the following resultMap definition:
In 3.4.2 the
Yes, 3.4.3+ is stricter in that sense and your code worked with 3.4.2 because of the bug fixed in #895 .
With ≤ 3.4.2 , auto-mapping is applied to the property
The 3.4.2 behavior can be a problem when both columns are in the result set and
With the above example result set, the expected value of the property
Hope my explanation makes sense to you.
Sorry, I meant #895 (corrected the comment).
I am saying that your code is invalid and it was not supposed to work in the first place.
<result property="code" column="pppEEECode"/>
What you need to do is to correct the mistake (i.e. rewrite the query or the result map).
@harawata - I understand what you are saying, but I think that the previous behavior resulted in fallback behavior that could be construed as acceptable, making this not so much a bug fix, but a feature behavior change, and one that is not called out or made clear in any of the release notes or even that PR.
We just didn't realize that. I have added a note on the release note.