FYI, this thread originally started as a discussion about recursion, where relations between databases A → B → A is possible, but not able to be shown in Smart folders or hierarchical lists.
It’s turned into a discussion about self-relation, which is fine, but perhaps the topics need splitting?
1 Like
That is precisely what I was thinking. When you create your view, you have to define the levels and the path that makes sense for the view that you are building. You can’t just add the databases and let Fibery to decide the hierarchy.
To be clear I think I am asking for two things:
1) Self-relations at deeper/lower levels of hierarchy
I understand that by doing this you are prioritizing self-relations for determining the parent over the higher level of the hierarchy. But doesn’t Fibery already have a way of disabling this with the red circle. Wouldn’t that guarantee that this behaviour can be disabled if it is not desirable in particular circumstances?
Adding this capability would really enhance things like organizational structures, page structures, project/task breakdowns, etc. .
2) Extend search path for parent node to higher levels of hierarchy
This would be use the “hierarchical path” to search for where to place entities into higher levels of the hierarchy. Fibery already does this with the level immediately above it (e.g. maps Projects to Programs and Programs to Portfolios). But it stops there and places anything that has no immediate parent into the “No Portfolio” / “No Program” section. However, when there are higher levels of hierarchy available, I think it makes sense to continue the search for matches at those levels. As you said this is still limited to realm of one-to-many relations (Projects have maximum one Program and/or one Portfolio).
Again, if this is not desired in all cases, I think adding a switch or setting to prevent it would be the answer (i.e. enforce strict hierarchy).
My comment about the “root items” was simply that in case you have self-referencing items, you only need to do this extended search for items that have no self-parents (i.e. Projects that have no Projects as parents). That should save some time in the process. I think @Matt_Blais was thinking along the same lines:
Many-to-Many Relations
I don’t think there is any way of allowing hierarchical lists to display many-to-many relations without allowing the entities to appear more than once in the view. If there is a technical reason that is not possible, then this will likely never be possible, unless a very complex logic/rule engine is added to decide where to put one and only one instance of the object.
However, if an item can appear more than once, then in the case that @jean1 offered:
the solution seems simple in this case. Depending on how the view hierarchy is setup you would either:
-
Add each Feature to every Product (assumes Product is at level 1 and Feature at level 2)
-
Add each Product to every Feature (assumes Feature is at level 1 and Product at level 2)
Now lets say that you add another database called “Bugs” and establish many-to-many relations like [Product] *------* [Bug] and [Feature] *------* [Bug]. In this case we assume that Products generally can have bugs as well as specific Features. I think this is probably the most complicated you can get with the structure.
I think the search path proposal described above would still be the way to go here. However, instead of stopping when you find the first parent, you keep going up the hierarchy to find other matches.
So if the view is setup like this:
Then again (assuming Bugs, Features and Products are not self-referencing databases), you would start with the list of Bugs and for each Bug, try and find all related Features and add it to all of them. If the switch (added to mockup above) is set, the algorithm continues to higher level of hierarchy and see if the Bug also has any relations to Products and adds them where the relation exists. Once that is done, the we move onto Features. From here the process the same as what we described above (item 1 of the list).
Apologies if this is belaboring the point. But this is one of the features that I really like to see in Fibery and thought I should offer every bit of thinking that I’ve had on it in case there is something here that would help make this happen.
3 Likes
That is true. I think we went in this tangent after your second post and focused on self-relations. I leave it up to you if we should split the replies into a different post. As you said there are inter-related discussion along with the many-to-many conversation.
I think your original question is a very interesting situation that I can’t quite wrap my head around. Are there some examples of A → B → A relation that you can provide?
I assume this situation would arise when you have two relations from B:
- Relation “Parent A” is defined as
[A] -------* [B] - Relation “Child As” is defined as
[B] -------* [A]
I think this will require allowing the same database to appear in the hierarchy more than once:
Or instead of adding databases to hierarchies, build the hierarchy based on relations:
I actually don’t have any idea how feasible this would be 
3 Likes
Thanks for engaging in such a great discussion.
I think your ideas are really valuable, and will stimulate some internal discussions around the topic.
Wrt A - B - A, my go-to example is a bill of materials:
A is a database of ‘parts’, and B is a database of ‘lines in a b.o.m.’ (which consist of a quantity field and a relation to a part).
Perhaps I should have shown it as A → B ← A since the idea is that a part may be an assembly (therefore is linked to multiple b.o.m. lines) and a part may also be present as the related part in b.o.m. line(s).
In practice, there is no way that a part can be a subcomponent in an assembly, which is then somehow a subcomponent of the original part(!) so there is no chance of an endless recursive loop, but the schema would in principle allow it :-/
It just feels like it would be nice if the hierarchical list view could allow navigating down through the entities from type A to B to A to B to A …etc.
Yeah, it was my fault, but it’s been a productive tangent 
3 Likes
Self-relations in all levels were added in latest release
4 Likes
This is a great addition and will make so many nested relations so much easier to manage 
There is one issue which hasn’t been addressed in the nested structure:
The nesting based on self-relation works fine if you have strict Portfolio → Program → Project Hierarchy. However, in some cases, major Projects might just be part of a Portfolio. In this case, even though the Project might have a relation to the Portfolio, fibery ignores that and puts the Project under “No Portfolio” > “No Program”:
I had suggested that as part of the algorithm, it would be beneficial if the search could continue up the hierarchy to see if a parent could be found for the entity at higher levels before giving up:
I understand this might not be desirable in a particular situation, so I also suggested have a way of toggling this behaviour:
This type of data model exists in a number of situations (project management, organizational structure, …), so I think there might be some value to considering it as part of the next iteration.
I hope this makes sense 
3 Likes