Closed jmathew closed 3 years ago
I actually think this is one we should probably leave as is. What's the functional need to have a circular reference here?
It changes the way I have to access the API on the client side. If I'm cutting up the returned object into separate client side objects in order to maintain the association between objects I have to either make a separate request for Child
with Root
as an include. Or I have to manually add it in as a transformation step.
Granted I'm retrofitting an existing application. So its possible if I designed this from the ground up with popcorn in mind I could avoid this. In my case the issue is actually that I have identifiers of parent objects (ex OwnerId
on a Pet
object) not able to be attached to child objects when requesting the Parent object.
I'm going to have a go at this.
Popcorn has self referencing loop detection which throws an exception whenever an include contains an object with a reference to a parent object. This is important in preventing infinite loops.
I think self referencing loops are only a problem if there is a self referencing loop in the default includes. If there are no loops in the default includes, the depth of nesting is defined by the
include
statement provided by the client. Which is to say it goes as deep as the requester wants it to but should never be infinite.I would like to keep the existing protection against self referencing loops with default includes but also allow for includes that include their parent object.
For example, given a root object called
Root
with a childChild
, I would like to have the following include on 'Root' be valid:[Name, Child[ Name, Root[ Name ] ] ]
.This should resolve to: