[OPENIDM-13953] embedded DJ explicit mapping returns null instead of  Created: 17/Oct/19 Updated: 04/Jun/20 Resolved: 29/May/20
|Component/s:||Module - Repository DS|
|Reporter:||Ladislav Folta||Assignee:||Dirk Hogan|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
OpenIDM: 7.0.0-SNAPSHOT 55394c2
|Sprint:||2020.06 - IDM, 2020.07 - IDM|
|Epic Link:||DS as a shared repo|
When creating user with on embedded dj explicit mapping, the effectiveAssignments is returned as null instead of an empty array like all other repositories do.
vs generic embedded dj:
or mysql explicit:
|Comment by Brendan Miller [ 23/Oct/19 ]|
Ladislav Folta As you marked this a regression, can you provide when/where it broke?
|Comment by Ladislav Folta [ 30/Oct/19 ]|
I went all the way back to M1 tag in January and it's still there. So it's been there for really long time.
|Comment by Dirk Hogan [ 07/May/20 ]|
The linked commentary very useful for understanding:
|Comment by Dirk Hogan [ 08/May/20 ]|
The issue is complicated. If https://bugster.forgerock.org/jira/browse/OPENDJ-5722 were implemented, DS would always return  for an unspecified multi-valued field, but these are not the semantics for JDBC, which can distinguish between an empty list and null for multi-valued fields. Thus even if virtual property calculation were always mandated to return  for an empty, multi-valued field (which is not currently the case for effectiveRoles/Assignments, or their java-based replacement), the DS/jdbc discrepancy would persist for non-virtual multi-valued fields:  can be explicitly stored in jdbc, but not in DS, thereby allowing jdbc to distinguish null and an empty list for multi-valued fields. If DS always returned  for null multi-valued attributes, effectiveRoles and effectiveAssignments might converge, but non-virtual multi-valued fields would not. If they are not explicitly specified in jdbc, null is returned, but post-OPENDJ-5722, DS will always return . If they are explicitly specified as , jdbc will return , but pre-OPENDJ-5722 will return null.
We discussed implementing these 'convergence' semantics in ContentFilteringSupport, but this would still leave the discrepancy at the repo layer, and prior to the managed prepareResponse processing, where ContentFilteringSupport is engaged. This discrepancy means that e.g. scripts would have to handle both cases. It would also leave the repo API divergent between DS and jdbc.
We discussed implementing this at a Filter in front of the repo layer, much like the 'edge augmentation' Filter for DS. Such a Filter would have to know about the field types defined in the managed layer, a bleeding across semantic layers which also should be avoided.
|Comment by Dirk Hogan [ 11/May/20 ]|
The decision was made to add a filter layer to managed/internal, via the AugmentingIDMConnectionFactoryProxy, to process requests as they return from the repo, and replace any null-valued fields of type array, as specified by the managed/internal schema, with ''.
|Comment by Ladislav Folta [ 04/Jun/20 ]|
Verified OK on 7.0.0-SNAPSHOT dfd37e7