I was trying to set up a relation between entities in the same type. I wanted to create a “related to” simple relation, similar to what you can do in Jira, Github, some other apps. I wanted to have this “many-to-Many” as there could be a need for a couple of such relations in an entity.
I notice though when I do this with the same entity Type, I get two fields on the entity. When I relate between any other entities, you only have the one field. I could see that this could be useful if you wanted to create a outward/inward relation, this is actually a good feature of Jira that is useful:
But I’d like to also be able to create a simple relation between entities in the same Type, but many-to-Many. Is this something you guys would consider adding?
Bidirectional links between entities of the same type would be very useful. Bidirectional links with associated semantic meaning would be amazing. Then be able to generate network diagram in whiteboard [falls backwards in chair etc]
I think the contexual back-refs are amazing and solve a large part of the problem. I will say I still have use-cases where I’d love un-directed/bi-directed links still.
Not a huge priority, just wanted to register that it still would be great!
Yes, thanks @colman. I still have need for the actual Relations vs. Bi-Directional. The views, for Example, are very well-thought out when you have a Relation vs. just a “mention” via Highlights aka “Bi-Directionals.” And Formulas, and to come Automations, I believe won’t work without a relation?
I find more and more use for the “self” relationship that is formal like this, not ad-hoc like backlinks, and very little - if ever - do I have a need for the two fields (“outgoing” and “incoming” links??). Usually I just want to show that two entities of the same type are related. I’m surprised this is hard to implement or seems unusual.
As @colman has said here, I think that there are use cases for all variations that would benefit from having two fields.
For example:
one-to-many:
employee being subordinate of other employee - it is nice to see both ‘manager’ and ‘direct reports’ for a given entity
one-to-one:
rowing partner in a coxless pair - one person will be rowing strokeside and one will be rowing bowside, and it’s nice to show which is which
many-to-many:
team members, where one person is the team leader (+ a person may be leader of more than one team and/or may be (non-leader) member of more than one team) - being able to show leadership and membership roles separately might be useful.
To be honest, this last one probably lends itself to creating a new type (= team) with a many-to-one relationship to team leader and a many-to-many relationship to team members, or even some other solution.
Anyway, they were just the first examples off the top of my head.
Of course, it’s possible to think of examples for each type of relationship where only one field really needs to be shown, so I’m not saying that having two fields is always right. Perhaps when the fibery team release the ability to hide/show fields, then the problem goes away, since showing only one field is obviously a subset use case of showing both
Interesting point. I feel weird about relations fields being there that aren’t being used, like maybe it creates some performance overhead or something, for no benefit. Probably not, if the relation is already there and simply expressed as two fields…
In any case if it were a dev time choice between “implement hiding of fields” and “implement single-field relation to self” I’d vote for the former, certainly. I doubt it comes to this, but maybe it can factor into the decisions.
I could be thinking about this wrong, but hiding one field won’t solve the problem. In the current Fibery directed relationships, the two fields mean different things, it implies a meaningful asymmetry. A common example would be something analogous to a parent-child relationship.
You can see that if you create the self many-to-many and give them very different names, say Parent and Child, adding entities in the Child box shows them in the Parent box on the target entity.
Thus hiding one field won’t work here: if you added entity X into entity Y’s “child” box, hiding parents in general means that if you looked at entity X, you’d see no reference to entity Y.
In theory a “collapsed” view of both could work, but this is functionally a unidirectional relationship (or undirected), so really then the problem is solved.
Good point @colman although I have to say that if the need is for a ‘peer-to-peer’ relationship (with only a single field showing) then I wonder what the meaning of the grouping would be and whether it might be served by another solution.
See my comments here:
If the issue of showing more info for children is solved, then peer-to-peer can be achieved with the addition of a relation (many-to-one) to a ‘group’ type.
For the time being, you can link items to a group and then add a (read-only) lookup to show other peers in the same group.
