@chris, I fully agree on a lot of things you said. Especially the thing-type-versioning which would solve a lot of issues (and already implemented in ESH days in my initial contribution of the onewire binding and then remved in the review process).
Until that is solved (and we still have textual configuration), automatic link deletion does more harm than the orphaned links. That’s why I implemented the manual “cleanup”. I would like to see a button in the UI to do that.
To summarize why I don’t think that automatic link deletion is useful:
A reload of a textual defined thing removed the thing and adds it again. Automatically deleting links defined in the UI (in .items files they will of course be safe) if the thing vanishes would require adding all links again if you change anything in the thing file.
As long as updated thing definitons require removing and adding the thing (in the UI), removing the links would require a full reconfiguration, while links would automatically be “re-added” when the thing is re-added.
@J-N-K we can of course limit this to only work with managed things, so it is perfectly possible to only provide this function for things configured through the UI.
I don’t use text files, but I assume given you provided this function to remove links that even for unmanaged things, the links still go in the jsondb?
If it was up to me to decide, I would have removed the text files completely. 90% of the problems results from either wrong documentation or mis-understood documentation regarding the textual configuration. We have tons of bugs in Githib issues because channels are linked to wrong item-types which is not possible in the UI. The only reason why they are useful is that copy-and-paste is not possible within the UI (because it is not implemented).
For historical reasons my items are all in text-files (because linking oh1-bindings to items required text-files and adding meta-data was not supported in PaperUI). My things are all managed.
You can define links in the items-definition in the text-file (also for managed things) and you can define the links in the UI. Only the latter can be removed by the tool.
I think a lot of the challenges this causes could be solved with additional parameters to some of the delete operations in the REST API: for instance when deleting a Thing or an Item you could add something like ?deleteRelationships=true or similar and that will delete all links that reference it, that way if you explicitely delete a thing or an item from the UI my guess is that you want the relationships to be deleted as well, so it will add this query parameter.
By the way, this should be added for group and metadata relationships as well, not only links.
If you delete an item, and it is a group, you might or might not want to fix the parentGroup reference on the members (usually you do). Same thing for metadata.
Could you elaborate what kind of problems? Because I often like to use a number item instead of a contact or a switch.
This is not a problem with textual configuration because it’s possible to do this through the rest api, too. If there are incompatibilities or possible problems at least a warning should be logged once the item is created.
No only that but it’s a system to group item definitions together. Also it’s possible to block edit, regex-replace on a certain scope only, share certain parts of the configuration over multiple openhab instance, etc… .
There have been lots of arguments about it and I don’t want to start one again, just state that it is not just “copy paste”.
The “bookkeeping” should be smart enough that this is not required.
Definitely. And for items it is really easy to do this consistently because there is a possibility to update the item without removing it.
Imho it comes down to this:
If I can update everything without deleting it then it is safely possible to clean up on deletion.
For items this is already possible (e.g. Groups/Metadata handling could be tackeld already).
For things it’s currently not and this is why we have strange behavior.
@Spaceman_Spiff E.g. Linking a Number channel (color temperature) to a Dimmer item results in exceptions if the color temperature is not withing the 0-100 raneg acceptable for PercentType.
