Is your feature request related to a problem? Please describe.
I can’t delete duplicate relations, and I would also like to retain the relational connection of an object i.e. retain a workout relation on a template even though I picked the other (duplicate) workout relation when I created it.
Additionally, I understand the need for relations to not be accidentally deleted and think true deletion may hinder that goal.
Describe the solution you’d like
The ability to merge 2 relations. I could see this theoretically only being able to happen within the store so as to prevent accidental merges.
This appears to solve the problem of deletion wiping relevant data from objects while also not cluttering up my personal set of relations with too many accidental double relations.
Describe alternatives you’ve considered
Delete function added to relations
Additional context
Add any other context or screenshots about the feature request here.
Agreed! I’ve accidentally made a few unwanted relations while playing around and would love to be able to ‘remove’ them somehow as they are cluttering things up and could get confusing over time
I also agree that relations should be able to be deleted or “locked” so it cannot be done by accident. Maybe a security by having to type “DELETE” or something when doing so ? or a hide function that prevents them from popping up in search or when inputing a new one ?
This could prevent duplicate relations and allow for removal of the ones you are sure to never need.
I like that idea for having to type “DELETE” or “MERGE” to confirm the merge/deletion. (Or even just a confirmation pop-up.)
I’d be worried with a full deletion that you would be unable to retain important information on an object (that maybe you forgot about) when you delete a relation outright, but I can see a situation where you would just want to completely wipe the relation (and its data throughout your Anytype).
possible solution to this:
Have 2 options, “Delete this relation, and all of its links to object, relevant data, and sets within Anytype” and “Merge this relation” which would then prompt you to pick another relation to merge (relation 1) with (relation 2).
From a software (back-end) perspective, I am unsure which of these two options are particularly viable considering I don’t really understand the structure that supports relations and sets. Depending on the underlying structure, Merging could be much simpler – as simple as hiding one relation and creating/changing a pointer from relation 1 to relation 2-- or deleting could be much simpler, but I can see a reason for users to have access to both types of manipulations of relations at some point in the future.
For now, I think having one of the two options is more critical than having both .
@mitch There are no delete capabilities yet. So, experiment, but keep in mind you won’t be able to delete your experiments yet. It’s a complex problem to solve (see discussion here: https://community.anytype.io/t/-/1596 ) but definitely a priority.
If there is a relation deletion or relation merge about to be executed, there should be a warning on how many relations will be affected in the overall database in one’s Anytype.
That way, we get a heads-up on how much data that we will affect after performing a delete or merge. We can have the necessary screening and adjustments when needed before continuing it.
This feature can mess a lot of things if not treated with a set of protocols. Imagine blindly deleting or merging an existing relation that is attached to hundreds of objects that have a different context, and then changed just like that.
As an example case, ‘polish’ can be put in a context as in people of Poland and also as in burnish in carpentry.
When he changes the tag type relation that is written as ‘polish’ and changes that into ‘gloss’. It will be relevant in his notes, articles, or books (and any other objects) that talks about carpentry. But it will be an irrelevant tag in his objects that has the topic about something related to Poland or the history of it.
Just the ability to rename could make our life easier, as we would be able to add a prefix or suffix to the name of the relation to identify it as duplicated. I guess that is easier than implement the delete feature.
It’s a complex problem to solve (see discussion here: 
someone might even end up asking what is a ‘gloss’ stage on the daily stand up LOL 