Closed bwosborne2 closed 3 years ago
I probably won't implement this - it's quite complex and very easy to do manually in the relatively rare occasion it's needed.
This is at least the way we've always done this - it's the same in the new and old database and I don't personally think it's worth spending quite a lot of time when this is not used very often and is so simple to achieve manually.
Does that sound ok?
I just thought adding additional database checks would suffice, but you're the boss...
The process should be documented in the database reference guide though. I may have missed that.
The issue is the IDs. Of course if you want to do this, since you did much of this import script, then I'm more than happy to have it improved as clearly that would be better. I just think that for the number of times this is used the benefit is not so high.
I think the docs are there - like everything though, it was probably written by me and therefore may not be so obvious, but it says -:
Adding a new version of an existing device
If you have a different version of a device in the database, before adding another entry to the database, check that the association group configuration, parameters, and channels are the same. If they are, then it is only needed to update the device IDs of the existing device. If there is a new version required because the above data has changed, then first edit the exiting devices versions so that it does not conflict with the new device, then you can add the new device.
Before adding the new version (ie uploading the XML), change the type/id to a random number. This avoids any consistency issues when importing into the database. After the file is imported, change the type/id back, and set the firmware versions appropriately.
I'm very happy to have any improvement suggestions though :)
first edit the exiting devices versions so that it does not conflict with the new device, then you can add the new device.
That is what I tried. No mention of messing with device ids. The script is not currently in the repo, IIRC.
Perhaps we need a private repo for some of the internal parts of the web site.
That is what I tried. No mention of messing with device ids.
Hmmm, looks like there is? It says -:
Before adding the new version (ie uploading the XML), change the type/id to a random number. This avoids any consistency issues when importing into the database. After the file is imported, change the type/id back, and set the firmware versions appropriately.
The script is not currently in the repo, IIRC.
I think that's right, but you have access to the site so it's fine if you want to take a look.
Do you want this in the public repo? It pertains mainly to the backend database interfacing. I suggest a new private repo for these parts.
but you have access to the site so it's fine if you want to take a look
That was my plan, with your blessing ;)
I just tried to add a new firmware version of an existing device. I first changed the maximum firmware version of the existing one to 3.255. The xml import fails with this error
This Issue is to remind us and to permit me to submit a PR to correct the logic.
I believe this issue also existed on the old site. IMO we should be able to: 1, Update old entry max firmware