-
-
Notifications
You must be signed in to change notification settings - Fork 261
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
DtoQuery may match the wrong constructor #3062
Comments
Well yes in this example there is are two constructors that both take 3 parameters. Ebean is expecting us to remove one of those constructors so that there is only 1 constructor that takes 3 arguments. I wonder if what you mean here is that Ebean should automatically ignore the constructor that takes the So there is no "bug" here, we just can't have 2 or more constructors that have the same number of arguments. |
yes,maybe think about if find one more constructor,return DtoQueryPlanConSetter or DtoQueryPlanConPlus? |
Do you mean, in this case Ebean finds 2 constructors that take 3 arguments ... so it should then ignore both constructors [because it will not be able to resolve which one to use], and hence the only constructors it should use is the |
When 2 or more Dto constructors clash by argument count then we need to ignore those constructors.
#3062 - DtoQuery may match the wrong constructor
Yes, this is effectively the fix for this. |
Maybe the documentation needs an update to be more precise? Currently it says "Firstly we look for a constructor with the same number of arguments as columns in the resultSet. If we have such a constructor we use it for mapping (assuming the correct types)" A reader could very well understand that if Ebean finds two or more constructors of the same length, Ebean would then choose the one with the correct order of parameter types. That is kind of what I would expect too. If the result set contains String, String, int then search for a ctor with 3 (or less parameters if setters exist) in the order String, String, int. Given that many people (I assume) use default build tool settings class files also almost always have debug symbols included including parameter names. So these could be used most of the time as well. I assume that if Ebean decides to look for setters as well these need to be done by name anyways, not just by type, right? |
We have many more Java types than database types plus for the case of number types and Date/Time types there are multiple matching possibilities so no DtoQuery constructor matching is just simple and based on argument count.
Setters are matched by name yes. |
when dto have some diffrent constructors,only match constructor with constructor's args length can't find the right constructor
demo dto
The text was updated successfully, but these errors were encountered: