Get rid of relationship name

[manuelma]

I couldn't find an issue about this, but I think we should get rid of the relationship 'name'. We never use it for anything purposeful, do we? But we still need to manage to find a unique name for each relationship so we don't violate the unique constraint in the db.

[soininen]

I haven't seen it used nor shown anywhere. It's basically duplicating information from relationship class name and object list and is an annoyance to keep up-to-date.

[DillonJ]

It's probably the right thing to do - to get rid of it - but I think the intention was originally that we could have multiple relationships between the same members for the same relationship class. I know use cases have arisen over the course of the last few years that could have used this - but it turned out that our implementation relied on the fact that this would not be the case - SpineInterface convenience functions in particular.

I guess we would be closing the door to functionality that could exploit multiple relationship instances between the same members but the reward is lower cost of maintenance.

If the work saving is minimal I would tend to leave the door open. However, if it's a major pain to maintain - then we could lose it

[manuelma]

I guess we would be closing the door to functionality that could exploit multiple relationship instances between the same members but the reward is lower cost of maintenance.

We can reopen the door anytime it becomes meaningful, but there are so many things that are pushing to close the door at present: pivot view in Spine DB Editor, SpineInterface, import functions, the JSON format (used by SpineOpt template among others)...

I'm not sure what those use cases are that would benefit from relationship name, maybe we can try and list them here if it helps the decision?

[DillonJ]

I was more making the general point that from time to time it would have been useful.

Multiple 1-D relationships of the same class would be one use case - I don't think that is supported at the moment.

[jkiviluo]

I would really have liked that functionality when doing FlexTool 3.0. I would have rather had just nodenode to represent connections, but I had to make extra object class connection and then `connectionnode__node` to represent the relationships.

I'm not 100% sure no one is using relationship names for anything right now, but I suppose not. Still, I hope we could one day get it working with all functionality. Meanwhile, I guess it can be removed to reduce maintenance. I'm sure we'll hear if someone's system breaks (and probably not, since it's not supported elsewhere than in the DB).

[soininen]

I would really have liked that functionality when doing FlexTool 3.0. I would have rather had just nodenode to represent connections, but I had to make extra object class connection and then connectionnode__node to represent the relationships.

I'm not sure I follow: what prevented you from using a 2D relationship to represent connections in that case?

[jkiviluo]

Because there can be multiple connections between two nodes.

[jkiviluo]

Becomes pointless with Entity in v0.8.