-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Remove parameter name restriction when assigning keys generated by multi-row insert. #1249
Remove parameter name restriction when assigning keys generated by multi-row insert. #1249
Conversation
…y multi-row insert.
} | ||
|
||
private Object getSoleParameter(Object parameter) { | ||
if (!(parameter instanceof ParamMap || parameter instanceof StrictMap)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could it support following code ?
List<Country> countries = ...;
SomeBean someBean = ...;
Map<String, Object> params = new HashMap<>();
params.put("list", countries);
params.put("someBean", someBean);
sqlSession.update("...", params);
In this case, is need to use the DefaultSqlSession$StrictMap
as follows ?
List<Country> countries = ...;
SomeBean someBean = ...;
Map<String, Object> params = new StrictMap<Object>();
params.put("list", countries);
params.put("someBean", someBean);
sqlSession.update("...", params);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, @kazuki43zoo .
This PR does not support it (I intentionally dropped it, but forgot about it).
With this PR, when calling SqlSession methods directly (i.e. using XML mapper only), the target list, collection or array must be the only parameter.
Do you think that usage is important?
If so, I would take a different approach i.e. 1) introducing a new syntax list[].id
for keyProperty
(this was proposed in the original issue #324) or 2) introducing a new option keyCollection
to specify the target list, collection or array.
@jeffgbutler , You reviewed the original PR. Any thoughts on the spec?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think that usage is important?
No. However, I prefer to announce dropping backward compatibility and introduce workaround in a release note(or migration guide).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it should be mentioned in the release note.
By workaround, you mean the code using StrictMap? I thought that was an internal class.
The workaround I had in mind was to use Java mapper. Could this be a big limitation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By workaround, you mean the code using StrictMap? I thought that was an internal class.
The workaround I had in mind was to use Java mapper.
I agree.
# Conflicts: # src/main/java/org/apache/ibatis/executor/keygen/Jdbc3KeyGenerator.java # src/test/java/org/apache/ibatis/submitted/keygen/Jdbc3KeyGeneratorTest.java
int insert(
@Param("list") List<Country> countries,
@Param("someBean") SomeBean someBean); If this pr is merged, can param name be named arbitrarily instead of the specified "list"? |
Thanks for the comment, @lovepoem !
Yes. For example, you can name the parameter 'countries'. int insert(
@Param("countries") List<Country> countries,
@Param("someBean") SomeBean someBean); The <insert id="insertListAndSomeId" useGeneratedKeys="true"
keyProperty="countries.id"> |
If so , It look good to me It's a good pr |
…ement-2 Remove parameter name restriction when assigning keys generated by multi-row insert.
Currently, to assign keys generated by multi-row insert, the target parameter must have a special name (i.e. 'list', 'collection' or 'array').
Many users found this restriction unintuitive and inflexible (I agree).
This PR removes the restriction so that the target parameter can have any name.
It comes with two backward incompatible change, though.
keyProperty
must include the parameter name.See below for the details
1. When there are multiple parameters,
keyProperty
must include the parameter name.Let's consider the following insert statement which takes two parameters.
Assuming that you want to assign generated keys to
id
property of eachCountry
inserted.In version ≤3.4.6, the correct value of
keyProperty
wasid
.Once this PR gets merged,
keyProperty
must be specified aslist.id
.2. When calling SqlSession methods directly, the target list, collection or array must be the only parameter.
With the following code, the generated keys were assigned to the 'list' parameter in version ≤3.4.6.
This PR does not support this usage.