kqarryzada
commented
1 year ago Thanks for the detail and background on this. RFC 7643 does not discuss the use of graph databases, and it also doesn't discuss bi-directional or circular relationships between attribute definitions or resources. Thus, this behavior isn't defined by the specification, so I don't think there's a clear answer for how a SCIM application is supposed to behave when using data of this form.
I think we'd be reluctant to remove this validation at this time since it's unclear how this would affect other types of databases where this validation makes sense.
Is your feature request related to a problem? Please describe. A clear and concise description of the problem that would be solved by this feature.
I'm working with a graph database and I'm using bidirectional relationships. In building the API my response objects must support this type of relationships, SCIM is part of the solution I'm implementing, but the current version of the framework doesn't support bidirectional relationships.
When I annotate the response objects with bidirectional relationship the framework returns the error "Cycles detected in the schematic"
In this code
https://github.com/pingidentity/scim2/blob/69ae34dd2cc6bc9d6b3b32cc14b89f325211897d/scim2-sdk-common/src/main/java/com/unboundid/scim2/common/utils/SchemaUtils.java#L174-L178
I didn't find any limitations about bidirectional relationships in the RFC but this code makes the implementation unfeasible. Is this a RFC limitation?
Would it be possible instead of throwing an exception just not looping through the repeated objects (as jackson does) to avoid infinite recursions?
Can we address this by returning null for repeated objects?
As graph database is increasingly used, I believe that exception will make some other projects unfeasible.
Describe the solution you'd like A clear and concise description of what you want to happen.
It would be important do not throw an exception when we encounter cyclic objects, we might just not process them the same way jackson implements it.
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
I believe that returning null for those objects would be enough.
Additional context Add any other context about the feature request here. This is an example of a graph database modeling with bidirectional relationships.
Please let me know what you think about that. Thanks in advance!