I thought the database logic checked for that and rejected them both until someone resolved the issue.
It usually does, no idea what happened here …
It does, and it did - there is no duplication in the database.
The issue is there is only 1 database entry, but since the thing type uid was changed, it is now duplicated in the binding it seems - ie the same database entry has now ended up with two files since the names have changed.
1 Like
Let me rephrase it: we have two devices in the binding, but only one in the database 
The culprit is here:
I think I deleted that entry and added the thing type and id to
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/889
But why did it get into the binding?
This is due to the change in the thing uid - it generates a new file, and the database doesn’t (ie it can’t) remove the old file. To do the full database export and update takes a lot of time as there’s well over 1000 entries now, so I don’t do that each week - the weekly update will just add and update existing entries. I then tend to do the full update a few times a year to remove any things like this that haven’t been caught.
Should the thing uid, once validated, be displayed as readonly so it cannot be changed? That would make sense if it must be unique. The only way to change it then, would be to delete the old entry & enter as new. I assume database deletes (marked as do not use) are reflected in GitHub.
I could possibly make it so that users can’t change it - I’d want to avoid making it so that admin can’t change it as sometimes it is needed for various reasons.
I’m not sure, but probably not until the full export is done. It’s pretty rare that entries are deleted after being released - mostly we delete them before release when doing the review.
I remember you doing a bunch when I audited the database last year.
Another idea would be to warn of the thing uid change in the email so you could delete the old GitHub entry manually?
Unfortunately for the same reason as it’s not easy to delete the files, it’s also not easy to do this. The problem is that the thing uid gets changed before the notifications are sent. ie -:
- User changes stuff - maybe they change the uid
- User presses the “request review” button - there’s no way to know that the uid now is different to before. I know there’s the diff that’s made, but that is a simple text comparison and can’t easily or reliably check certain fields of the database.
Hiding it so users can’t edit it is not hard though so that could be done reasonably easily.
This should now be hidden for users unless it’s not set.
1 Like
So if the thing uid is changed the old one is marked as hidden? That should work.
So, just curious… How long before the fix I need is in the binding?
1 Like
I will hopefully do a binding update tonight, so it will be available tomorrow.
1 Like
Sorry! Forgot to update!
This is working now after the new binding update!
Thanks all who helped out!
1 Like