Wrong handling of positional INOUT parameters when extracting output parameters
thjanssen opened this issue · comments
When extracting positional output parameters of a stored procedure, the StoredProcedureJpaQuery.extractOutputParameterValue
method tries calculating the position of an output parameter based on its index and the number of input parameters (https://github.com/spring-projects/spring-data-jpa/blob/main/spring-data-jpa/src/main/java/org/springframework/data/jpa/repository/query/StoredProcedureJpaQuery.java#L146).
Based on some tests in a client project, the methodParameters.getNumberOfParameters()
method seems to count IN and INOUT parameters as input parameters. As a result the position of INOUT parameters get skipped instead of extracted.
Example: When extracting the output parameters of a stored procedure with 2 INOUT and 7 OUT parameters, the method tries to extract positions 3-11 instead of positions 1-9.
Thank you @thjanssen! You don't happen to have a test at hand that reproduces the problem?
I'm working on it. I hope to provide one by Monday
@christophstrobl I added a test case here: https://github.com/thjanssen/spring-data-jpa/blob/issue/3460/spring-data-jpa/src/test/java/org/springframework/data/jpa/repository/procedures/PostgresStoredProcedureIntegrationTests.java
It fails when I run it within my IDE, but the Maven build still passes. Any idea why?
BTW: The other test cases in that class were deactivated, but they seem to work fine. I've reactivated them on my branch.
Suggested fix:
Add position information to ProcedureParameter
class, set it in StoredProcedureAttributeSource.extractOutputParametersFrom(...)
, and use that position in StoredProcedureJpaQuery.extractOutputParameterValue
to get the result value.
This should work based on the assumption that NamedStoredProcedureQuery.parameters()
returns the parameters in the correct order. As far as I understand the rest of the code, it already makes this assumption when using positional parameters.
I did a quick prototype implementation of this fix. You can find it here: 5e19dba
The final version would need some cleanup, and the output format feels a little strange. But it seems to fix the issue without breaking anything else.