In the database world we very rarely delete anything; i.e. when a Person is no longer a Customer we don’t delete the Person, because the Purchase History would become orphaned… and it would leave a lot of nonsense in the database because other Objects need the Customer for Context.
What we do, is set a 'Status' = 'Inactive', or 'InactiveDate' = '20201018' or even both, then we only see the Customers we should, and only Active Customers can make Purchases. I don’t think the issue here is really obsolete data in the jsondb that’s unused, the problem is the framework doesn’t see it as unused so inappropriate things happen.
Given there are valid use cases for obsolete metadata - not to be confused with the metadata metadata (links are metadata too) - like merging a previous configuration after changes have been made, the obsolete records should be left intact but get flagged so the framework treats it properly, which in most cases will mean ignoring it. But when it does come time to delete it - assuming the user got the obsolete records merged into the new configuration - then it should be a deep cascading delete which does not upset the jsondb consistency.
Hi everyone.
I have a small question. How can i use the cli command in karaf for thing channel missing?
I can only use smarthome:links, but there is no option for orphan.
My system is an Ubuntu server with openhabian 2.5.8.
Thanks for helping,
Markus
Are you referring to simple mode? That no longer exists in OH 3 so there wouldn’t be automatic linking.
If you are referring to creating an Item from the Thing’s Channel and thereby automatically creating the link in the process, I fail to see the practical difference between a manually created Link and an automatically created Link. If you only consider Items defined in .items files to be “manually” created than what you are really saying is that the links should be removed in all circumstances where said links can be deleted.
I believe both rossko57 and I are arguing that such a system will cause a number of users some hardship.
Maybe my big problem with this discussion is which entity the Link belongs to. I think it’s clear that metadata “belongs” to the Item. So it makes a lot of sense to delete the metadata when deleting the Item it’s applied to.
But who owns the Link? The Thing or the Item or the Binding? To me it makes a whole lot of sense to delete the Link when the Item is deleted. I can see no argument for why that would be a problem because, as you argue with Rules, Items are something the user has to actually create (no more simple mode so no more automatically created Items).
Where I have concerns is when we delete the Link when the Thing is removed as it creates potentially a great deal of extra work for some users under some circumstances. I have something like 45 Network binding things. If there is a patched version of the binding released where I have to uninstall the binding and manually install the patched binding for testing it would be a significant hardship if I were forced to recreate the Links. It would nearly double the amount of work I’d have to do.
So even if by default we delete the links when the Things go away, having an option not to do so because I as the user know I’m going to put those Things right back is important to me.
Sorry, if I’m mistaken, but why not simply ASK the user about this?
After (or while) deleting a binding, simply show a popup:
“Do you want also delete the attached links became orphans too? (list comes here…)” YES (recommended) NO (for advanced users)
…
Maybe even explain with a few sentences or (i) info what happens in both cases:
some log errors can occur, if you do not delete them,
but you don’t have to go in and relink all your Items in the case the binding is being reinstalled, and the random ID was renamed to a meaningful name previously.
I think this is the fundamental question and I agree that it is the item that owns the link(s).
If an item would properly own the links (and metadata) this would solve lots of issues.
But currently these are two mappings totally independent from the item and I am unsure why it is that way and what problem it tries to solve.
I don’t see, why not making the GUI side easier just because the “advanced” = textual won’t handle it?
IMHO 90% of the novice users (like me) will use the GUI.
Why not make their life easier?
Personally I think I still have 20-30 unused, random named bindings at my config, because (as most of us at the beginning) we have TRIED to set up our house system in hurry while we were learning about all these “bindings” and “items” and things still a bit too much to understand and remember all.
But I don’t know how to identify if it’s an orphan one? Can I delete it? How?
If you (advanced) guys are asking questions like this, imagine us, “normal users / beginners” …
That’s why I agree with the idea:
The system should delete the orphen binding too, but ask the user first, if using the gui.
I guess those few advanced users who use textual setup can save their bindings in a text file too and restore with a copy/paste? (I have no idea, just asking… never used the txt setup before, didn’t seemed to me user friendly.)
Again: this is only an opinion, to show a perspective of a beginner. (I’m an advanced pascal programmer, but do not know enough about fine-mechanics of openhab.)
If Items owned links there could only be ONE. Links are owned by Links. Links are a bridge table which sits between ThingChannels and Items, and exist in isolation. The Links “bridge table” is required in order to support the many-to-many relationship.
The creation of entries in the “bridge table” should only be possible through creating/modifying an item.
This ensures that the links and items are always in sync. The same with metadata.
Deleting an item should remove the links accordingly.
So, the link is a simple relationship entity between two “nodes” in different tables in a database. It’s not “owned” by the Item or the Thing - it’s an internal mechanism that links them. It’s certainly not “owned” by the binding.
If you remove one end of the other, the relationship is broken and means nothing. Eg, if I delete the Item, then having a link from a Thing (channel) to a non-existing item doesn’t at that point make any sense. Same the other way around - if you delete the Thing (or change the channels in a Thing) and the Item remains, then the link makes no sense again as one end doesn’t exist.
That’s what I’ve recommended in at least a couple posts on this thread already. Delete the link by default but give the knowledgeable user the option to override the deletions.
Deleting the Links automatically is not possible when textual configuration is used anyway so does that really matter?
This isn’t really something that “normal users / beginners” need to care about. The discussion is primarily about what should OH do automatically on behalf of such users.
Than as long as at least one side of the bridge exists (i.e. the Item(s) or the Thing) the Link should remain, right?
Because it informs when the Link should be automatically deleted. If the Thing “owns” the Link than the Link should be deleted when the Thing is deleted but not when the Item is deleted. If the Item owns the Link than the Link should be deleted when the Item is deleted. If they both own the link than the Link should be deleted when either the Item or the Thing are deleted. If neither own the Link than the Link should not be deleted automatically unless both the Thing and the Item are deleted.
I don’t disagree with any of that. I just don’t want to lose the ability to delete a Thing when I know ahead of time that I’m going to replace it. So far I’ve heard no solution that would let me temporarily delete a Thing without the Link also being deleted. And without out that it will generate tons of work for some user in some circumstances. If deleting the Binding deletes the Things and deleting the Things deletes the Links than I know I for one will never test a pre-release binding for any binding I’m using that has more than just a couple of Things. The work required to relink everything would be too great. Heaven help us in the case where an update to a binding requires the recreation of Things to function at all.
I thought that maybe thinking about the problem in a different way would be useful. Apparently not.
This doesn’t really make sense to me - sorry. To me - you have a relationship - if you delete one element in a relationship, the relationship is gone. Neither end “owns” the relationship and I don’t think you can define it this way.
I don’t think anyone is talking about deleting all things and relationships when the binding is updated! Clearly that is not a wise thing to do. We are talking about a user actually deleting something through the UI - they delete the thing, or the item, and in this case, relevant links in this relationship should also be removed. That’s all.
Yes, catering to edge cases should not be the norm. It should do what is normal and customary, and options can be added to deal with edge cases.
No. Does a link have “Identity” and it’s own attributes? If so, then yes, Links can exist in their own right, with null parents. If not, then no, if either parent is deleted (ThingChannel, Item), then the Link in the bridge must go away - in that case the Links identity is a concatenation of it’s two parents, so without both parents it’s logically invalid and should be deleted.
The child own the Link. Children hold Foreign Key References to their Parent(s). Usually, the Entity that has a physical field which holds the link is considered to be the owner. Children hold their assertions regarding their Parental relationships. Parents can be claimed, but they do not own references. In many-to-many relationships the link is the child, and the child will claim parents of at least two types. As I said earlier, it the child in the bridge table Has Identity, then it can exist on it’s own, with null parents. If it does not then deleting either parents invalidate the link.
That is an edge case, where the are a number of ways to handle it, which often starts with flagging the Delete as more of an Update so that the thing gets swapped out without breaking it’s links.
I’m not talking about a normal update. I’m talking about these two cases, perhaps there are more.
Example 1
I use the Network Binding with 50 Things. The Network binding has a bug that makes it not work for me. The maintainers have patched that bug and posted a jar file I can download to test the patch and access the fix before the next release as I’m unwilling to move my entire OH instance to a snapshot.
Uninstall the Network binding.
With the changes talked about here, all 50 Things and Links for the Network binding will be deleted.
Manually install the patched Network binding by dropping the jar file into the addons folder
Now I have to:
a. Recreate and/or rediscover all 50 Things
b. Recreate all of up to 150 Links (each Network Thing has three Channels)
Today the steps would be:
Uninstall the Network binding.
Drop the new jar file into the addons folder.
Recreate/discover the Things.
If the names of the Things remain the same the work ends there.
Example 2
The Zwave binding has an update that requires the recreation of Things, as happened about a year or so ago IIRC.
Update openHAB to a new release.
Delete all the Things for the Zwave binding (except for the Serial Controller Thing) which also deletes the Links.
Rediscover the Things
Now I have to recreate the dozens or hundreds of Links back to the Things.
The problem in both cases stem from the fact that there is no way to tell openHAB the difference between the user deleting something because they want it gone or deleting something because they need to turn around and recreate it. All it’s just going to see that the Things was manually deleted and therefore the Links are deleted to. That’s why I’m asking for an option to tell OH not to do that. It doesn’t even need to be the default.
To some degree Rich, both these use cases are to work around other problems in the system - really the other problems should be resolved and then you wouldn’t need to worry about the links being removed
I agree - I tried proposing a mechanism to do this, by versioning the thing definitions and then providing a system where the user can update the thing through the UI, but this concept was rejected in the past as the ESH maintainers wanted a more automated system. I personally don’t want this to be automated (although it’s easy), but in any case I add this to my own system - maybe one day OH will have something .