Handle <bind> correctly inside <foreach>
#2760
Conversation
Also related to mybatis#206 mybatis#575
…phase - Evaluated param values are stored in `ParameterMapping` and later used in DefaultParameterHandler - There is no change when processing RawSqlSource - Removed unused `injectionFilter` from TextSqlNode (mybatisgh-117) This should fix mybatis#2754 . This might also fix mybatis#206 and mybatis#575 , but with this patch, it still is not possible to invoke a method with parameter inside a parameter reference like `#{_parameter.mymethod(_parameter.value)}`. It might be possible to accept OGNL expression in a param reference (e.g. `#{${_parameter.mymethod(_parameter.value)}}`), but I'm not sure if that's a good idea.
Although it is not the goal, this could improve performance when there are many foreach iterations.
|
Hi @harawata , there has been passed too many years since the last time I used or contributed to mybatis. I am afraid I cannot provide any useful nor updated info about this issue. The two-phase processing of dynamic queries was and is a very confusing topic for most users. I remember that there was a branch that process everything in the first pass caching bindings for the second pass... but it was never merged. I am talking about a very ancient history here. |
|
Thank you for the reply, @mnesarco ! It sounds like the branch took a similar approach to this PR, but you don't recall the reason why it wasn't merged, do you? |
|
It was long long time ago and I cannot recall the details, but I think it was not discussed enough and there were possible performance implications. I was trying to solve the same problem with bind tag. The basic idea was to implement bindings as function calls in the first phase that cache the output and assign a generated key to use at second phase, I did a POC but unfortunately I have no access to that code anymore. I started using JPA because of work requirements some years ago and I ended up implementing an internal tool to support native and jpql dynamic queries similar to Mybatis :D ... JPA has evolved to support also Stored Procedures and very felxible mapping scenarios... But I still miss some mybatis tricks.... BTW, java17's Records are quite sexy but not directly supported by JPA. Does current mybatis supports Record mappings with all the usual magic? Happy Holidays! |
|
Writing a custom tool for JPA sounds like you 😆 I couldn't think of any scenario that performs worse because of this change. Regarding the Records, SELECT should work the same way as classic immutable classes. |
|
Yeah generated keys are usually problematic. I am using a dedicated service for generated keys in many projects. And I am considering TSID[1] as a general approach. Vlad Mihalcea posted an interesting article about that[2]. [1] https://github.com/f4b6a3/tsid-creator But this is off topic. :D |
|
I did a quick profiling with JMH. <insert id="insertMultiRow">
insert into person (
id, name1, name2, name3, name4, name5, name6, name7, name8, name9
) values
<foreach item="item" collection="list" separator=",">
(#{item.id}, #{item.name1}, #{item.name2}, #{item.name3}, #{item.name4},
#{item.name5}, #{item.name6}, #{item.name7}, #{item.name8}, #{item.name9})
</foreach>
</insert>Only 500 items in the Throughput is pretty much the same and allocated memory is reduced significantly. @kazuki43zoo Please let me know if you noticed anything (even after this PR is merged). |
|
I am going to have to investigate the impact on mybatis-velocity and mybatis-thymeleaf first. |
|
hello @harawata , is there any benchmark about these mybatis velocity, thymeleaf and freemarker template plugins? Can I think that using the default mybatis solution will always be the most performant? sorry if the question is not related to the issue but we are studying mybatis to use in our new projects |
|
Regarding the other language drivers...
@GeorgeSalu , |
|
As this change affects mybatis-freemarker and mybatis-thymeleaf, the target milestone is set to 3.6.x. |
An attempt at fixing #2754
Related to #206 and #575
When processing
DynamicSqlSource, evaluate param values in scripting phase and store them inParameterMapping.This does not affect
RawSqlSource.Just to be clear, it still is not possible to invoke a method inside a parameter reference
like
#{_parameter.mymethod(_parameter.value)}.It might be possible to accept OGNL expression in a param reference
(e.g.
#{${_parameter.mymethod(_parameter.value)}}), but I'm not sure if that's a good idea.This should not break backward compatibility for normal usages, however, plugins that manipulate internal stuff might be affected.
@emacarron @mnesarco
If this does not seem like the right approach to you, please let me know!