-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 7.0.0
-
Fix Version/s: 7.0.0
-
Component/s: Module - Repository JDBC
-
Labels:
-
Target Version/s:
-
Verified Version/s:
-
Story Points:1
-
Sprint:2020.02 - IDM
-
Epic Link:
When the bindToken method of a LIST BindType is performed the indices are not incremented and the remaining tokens are bound to the incorrect position.
Example: Consider this portion of the SQL: "originproperty in (${list:originproperties}) AND originresourcecollection = ${origincollection} " in RelationshipResources
- Let the originproperties LIST contain: "reports", "bestFriend"
- Let the origincollection STRING equal "managed/user"
- The SQL string goes through the bindToken method the first time when it is for a LIST BindType and it comes out looking like:
"originproperty in (reports, bestFriend) AND originresourcecollection = '?' " - Then when the SQL string goes through the method on line 476 the second time it is for a STRING BindType and it comes out looking like:
"originproperty in (reports, managed/user) AND originresourcecollection = '?' " ... Notice bestFriend was overwritten due to the position being behind by 1 so it put "managed/user" in the position for 2 instead of the position for 3
We would expect: "originproperty in (reports, bestFriend) AND originresourcecollection = managed/user" but the binding is incorrect because the count did not increment for all list positions.
This started occuring when list logic was moved to the BindType enum in this commit https://stash.forgerock.org/projects/OPENIDM/repos/openidm/commits/609c0849ad9d61d8998f3a44bd6c0f58b4edde6f
- is caused by
-
OPENIDM-14067 500 response for numeric queryFilter comparisons with PostgreSQL repo type: explicit table
-
- Closed
-