When item is deleted, channel links should also be deleted

[cdjackson]

If I remove an item, channel links should also be removed and I suspect this isn't happening since when I add an item of the same name, and add a link, I get a 'link already exists' error.

I think ideally this should be implemented in the managed item since it ensures that no matter where the items is deleted, the links would also go. However, this looks like it would be a mess so it is possibly best to implement it in the REST interface?

If implementing in the REST resource is ok, then I'll look to add.

[kaikreuzer]

Note that links follow the general pattern that they can be provided through different ItemChannelLinkProvider implementations - so there is no way to delete links in general, only the ones within the ManagedProvider.
The REST API is imho not a good place for such a logic (I am just trying to get such stuff out there, see #1013).
For addressing your problem, I actually see a simpler measures: Change the behavior on the ManagedItemChannelLinkProvider from add to addOrUpdate - so if the link already exists, it will simply be replaced and you don't get an error anymore. Would that help?

[cdjackson]

Hi Kai,
Yes - that would also be fine. Generally, this shouldn’t be an issue if the UI also deletes the links, but I guess I was just thinking that having links to items that don’t exist wasn’t nice and it would be best to delete them when the item is deleted. As a work around though this would solve the problem in that no-one would know there’s lots of broken links - but they’d still be there…

I agree the REST interface is a bad place for this, but it would be nice to remove these links if possible (IMHO).

If we were to implement the addOrUpdate method, do you see this going into the AbstractRegistry, or somewhere else? I note that in the ItemChannelLinkRegistry doesn’t allow channel links to be updated (it throws an unimplemented exception)...

Chris

[kaikreuzer]

but it would be nice to remove these links if possible (IMHO).

I agree. Maybe this could be externalized into an house-keeping service for all managed providers...? I see more such issues upcoming in the future, where data might be out of sync (since we anyhow do not have transactions for the mapdb).

If we were to implement the addOrUpdate method, do you see this going into the AbstractRegistry, or somewhere else?

Good question. I would not want to change it in the AbstractRegistry, because it would impact all other Registries at the same time. Maybe would could even leave it out of the Registry and implement this on the REST resource - it tries to add it first, potentially catches an exception and then calls update instead (clearly we will have to implement the update method then).

[cdjackson]

I would not want to change it in the AbstractRegistry, because it would impact all other Registries at the same time.

Why not add it as a new method rather than replacing the existing add and update methods? It gives different implementations the option?

[kaikreuzer]

Ok, that could be an option as well, yes.

[cdjackson]

Also, there is no event sent when deleting a channel either...

I looked at implementing this a few weeks back as we discussed, but it's not so simple as in order to check for add or update, I needed to check if the link exists, and that requires the key which is not available.

Also, in this case, doing a relink when adding an item won't solve the problem that the event is not sent when the link is removed. In HABmin, I try and avoid polling for updates, so I rely on the events to keep things in sync between updates....

So, I suspect I might need to solve this in the UI by first unlinking the channel, and then deleting the item. I think this is the only place, given current APIs, where all information is available.

[kaikreuzer]

So the suggestion is we close this issue as "won't do"?

[cdjackson]

Well,I would argue that this still should be implemented to ensure a consistent state is maintained. Maybe we park this for now as the implementation isn't obvious, but I would suggest leaving it open as a reminder for any future optimisations

[kaikreuzer]

Question: Would you really want to have it automatically deleted, even if you e.g. have extensive properties and configuration on the link (wrt #583)?

[cdjackson]

Well, I would say that if we've deleted the item, then we should also assume that all its configuration is gone.

It's the same as the discussion we had a while back about deleting the things attached to a bridge, when you delete the bridge. I think that once people delete something, they should expect it to be permanently gone, and it should flow down to anything attached?

[kaikreuzer]

ok, I guess you are right.
When implemented, it should probably be done directly between the ManagedProviders. Maybe we would have some new listeners or events for that purpose.

[maggu2810]

My 2 cents:
I agree with @cdjackson that this should be implemented some time.
I am fine that the configuration / properties on a link between item and channel are dropped if the item is deleted.