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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generic type parameter is not correctly resolved when the class hierarchy is deeper than 3 levels. #1260

Closed
pavelda2 opened this Issue Apr 19, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@pavelda2
Copy link

pavelda2 commented Apr 19, 2018

MyBatis version

Probably all (Tested on 3.4.6 and 3.5.0-SNAPSHOT)

Database vendor and version

Probably all (Tested on ORACLE and HSQLDB)

Test case or example project

Pull request #1259

Steps to reproduce

Run test case from pull request #1259

Expected result

MyBatis should automap NUMERIC database type to corresponding Java type based on class inheritance.

MyBatis can do that when generic filed is specified in parent class or parent of parent class. But when generically typed field is specified in higher level of inheritance, MyBatis does not recognize generic type correctly and automaps default type for NUMERIC database type, which is BigDecimal.

Actual result

NUMERIC results in BigDeciaml instead of Integer.

@kazuki43zoo

This comment has been minimized.

Copy link
Member

kazuki43zoo commented Apr 19, 2018

Probably, the TypeParameterResolver#resolveReturnType does not return a correct type.
I've tried following tests.

@Test
public void concrete1() throws NoSuchMethodException {
  Assert.assertEquals(Integer.class.getName(), TypeParameterResolver
      .resolveReturnType(Concrete1.class.getMethod("getId"), Concrete1.class).getTypeName());
}

@Test
public void concrete2() throws NoSuchMethodException {
  Assert.assertEquals(Integer.class.getName(), TypeParameterResolver
      .resolveReturnType(Concrete1.class.getMethod("getId"), Concrete2.class).getTypeName());
}

@Test
public void concrete3() throws NoSuchMethodException {
  Assert.assertEquals(Integer.class.getName(), TypeParameterResolver
      .resolveReturnType(Concrete1.class.getMethod("getId"), Concrete3.class).getTypeName());
}

concrete1 and concrete2 are successful.But concrete3 is failed.

@harawata

This comment has been minimized.

Copy link
Member

harawata commented Apr 20, 2018

Thank you for the test case, @pavelda2 !
It really helps. :)

As @kazuki43zoo pointed out, there seems to be a bug in TypeParameterResolver.
I'll look into it.

@harawata harawata changed the title Bug: Incorrect NUMERIC database type automapping to inherited generic field Generic type parameter is not correctly resolved when the class hierarchy is deeper than 3 levels. Apr 21, 2018

@harawata harawata self-assigned this Apr 21, 2018

@harawata harawata added the bug label Apr 21, 2018

@harawata harawata added this to the 3.5.0 milestone Apr 21, 2018

@harawata harawata closed this in a60f3a9 Apr 21, 2018

@harawata

This comment has been minimized.

Copy link
Member

harawata commented Apr 21, 2018

Hi @pavelda2 ,
I committed a simpler test case, but verified the fix with your test cases as well.
It would be great if you could test your solution with the latest snapshot to verify the fix.
Thank you!

@pavelda2

This comment has been minimized.

Copy link
Author

pavelda2 commented Apr 22, 2018

Hi @harawata, latest snapshot fixed the problem in my solution. Thank you.

h3adache added a commit that referenced this issue May 5, 2018

fixes #1260 When scanning super types, replace type variables with ac…
…tual types.

As a side effect, it now returns more accurate result when involving type bounds. See the change in the existing test case.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment