This proposal proposes a slight rework of the Circle concept, adding mainly recursion and changing some small things.
Current situation
To the right you can see the current connections between Circles
New situation
Changing Global Circles to recursion
Looking at actual usecases the current proposal using Global rules definitily makes sense: this would probably suffice in most cases. Looking at it implementation wise however it does not really make a lot of sense. Implementing it this way made it clear to me that the two classes have a very high amount of overlap and causes the API to be a bit wonky.
As both GlobalCircles and BodyCircles are nearly identical, the difference being a relation to a body and parent Circle I propose to remove the concept of a GlobalCircle and letting instead have a single Circle be able to store a parent Circle on top of a contextual body it is related to.
Aside from cleaning up the code and API, this would remove the unecessary limit that is currently set on having a tree depth of 1 and adds additional future flexibility, even now allowing a root Circle (prev. GlobalCircle) to be linked to a body, which can be used for example to link commission assistants to the commission Body itself. Mostly, it has nearly no downsides, in practice it will likely mostly be used for a 2-level tree, but why restrict it on a DB level? If we want to restrict this it would be better done through logic.
The new proposal can be seen on the right.
Wonky API example:
Having a different endpoint for selecting a single circle dependant on the Circle type:
Code Block | ||
---|---|---|
| ||
api/circles/bodies/{circle_id} api/circles/global/{circle_id} |