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

Already on GitHub? Sign in to your account

Unable to resolve result type when the target property has a getter with different return type #2834

Closed
vlcheong opened this issue Mar 2, 2023 · 6 comments
Assignees
Labels
Milestone

Comments

@vlcheong
Copy link

vlcheong commented Mar 2, 2023

MyBatis version

3.5.12

Database vendor and version

Postgresql 14.7

Test case or example project

I've a test case which is working fine on MyBatis version 3.5.11. When I upgraded to 3.5.12, I got No typehandler found for property exception when my app startup, I've included a minimal test.

Steps to reproduce

Clone this then run the maven test

Expected result

MyBatis able to map the property

Actual result

Failed

@harawata
Copy link
Member

harawata commented Mar 2, 2023

This seems like another side effect of #2804 .
I think we need to revert #2804 and release 3.5.13. :(

@epochcoder
Copy link
Contributor

This seems like another side effect of #2804 .
I think we need to revert #2804 and release 3.5.13. :(

Could also be a good idea, then there is time to plan the correct required javaType for a new major version

@hazendaz
Copy link
Member

hazendaz commented Mar 2, 2023

Yes this will be looked at again later. Keeping eye on things today and if nothing else reported will be reverting the original change and pushing 3.5.13 tonight.

@MaximeCheramy
Copy link

MaximeCheramy commented Mar 3, 2023

I'm also impacted but I also suspect that we are doing something wrong anyway...

I suppose this come from this change:

-        javaType = metaResultType.getSetterType(property);
+        javaType = metaResultType.getGetterType(property);

In this code:

    public Optional<Integer> getElementId() {
        return Optional.ofNullable(elementId);
    }

    public void setElementId(Integer elementId) {
        this.elementId = elementId;
    }

What would be the cleanest way to support optionals with MyBatis? With a new type handler and using Optional for both?

@jeffgbutler
Copy link
Member

What would be the cleanest way to support optionals with MyBatis? With a new type handler and using Optional for both?

@MaximeCheramy This is my opinion about your question...

  1. You should not use an Optional as a parameter and you should not store an Optional as a class variable - it is only designed to work as a return value and a local variable. IntelliJ will complain (rightly) if you use an Optional as a parameter. So I would not use Optional for both.
  2. Having the getter and setter use different datatypes is non-intuitive. It also breaks MyBatis (obviously), is not JavaBeans conformant, and will likely break other frameworks as well.

So I don't recommend either of your options. Instead, the convention I recommend is built around immutable objects:

public class Foo {
  private Integer elementId;

  public Foo(Integer elementId) {
    this.elementId = elementId;
  }

  public Optional<Integer> elementId() {
    return Optional.ofNullable(elementId);
  }
}

I use this convention in virtually every class in MyBatis Dynamic SQL.

MyBatis can work with a class like this, and the elementId() method looks a little cleaner IMHO. If you can't do the immutable thing, then I would write normal getters/setters as well as the third elemendId() method. But...strive for immutable objects. This is the one piece of advice I feel confident giving every developer.

@harawata harawata changed the title Mybatis 3.5.12 ResultMap Bug Unable to resolve result type when the target property has a getter with different return type Mar 7, 2023
@harawata harawata added the bug label Mar 7, 2023
@harawata harawata added this to the 3.5.13 milestone Mar 7, 2023
harawata added a commit to harawata/mybatis-3 that referenced this issue Mar 7, 2023
Result mapping java type resolution fails when the target property has different types for writing and reading. mybatis#2834
harawata added a commit that referenced this issue Mar 8, 2023
@harawata harawata self-assigned this Mar 8, 2023
@harawata
Copy link
Member

This should be fixed by #2841 .

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

No branches or pull requests

6 participants