search

OpenZWave / qt-openzwave

QT5 Wrapper for OpenZWave
GNU Lesser General Public License v3.0
105 stars 30 forks source link

OZW database handling #83

Closed bwachter closed 4 years ago

bwachter commented 4 years ago

While making this usable when installed through packages (opensuse tumbleeweed ones here I ran into some issues with database handling - mainly with ozw-admin, but it applies here as well, and as ozw-admin uses qt-openzwave for dealing with the database this is probably the better place.

On startup the system wide database gets copied to a new location, but it's not updated when the system wide one changes.

First question, why is it copied at all? Is it supposed to be user editable, or is it supposed to get updates via internet?

Second, in case that database copy is needed, wouldn't it make more sense to just keep the changed files on user side? I.e., for a lookup read users manufacturer_specific.xml, if there's an entry try device specific file from user, and on failure system wide. If there's no device entry check the systems manufacturer_specific.xml and try only the system wide device specific file.

Fishwaldo commented 4 years ago

As mentioned in the ozw-admin report - I havn't done much of anything relating to "System Installed" copies of qt-openzwave. The use case upto now has been purely around AppImages/Docker/Installer packages, so its probable a system installed library doesn't quite work right.

Essentially, if you have a System installed qt-openzwave and openzwave, then the qt-openzwavedatabase is not needed at all, and the app should just default to the config files provided by the openzwave installation.

bwachter commented 4 years ago

Is this copy step used for the appimage/container usecase?

If not I guess just adding the system path to the PossibleDBPaths should work.

Also I guess userPath only contains user editable configuration parts, and on a fresh installation would typically start with an empty directory? So the check there would just be if the directory exists, instead of the current check for options.xml as well?

Fishwaldo commented 4 years ago

I think you confused about userPath and dbPath:

1) dbPath is where the manufactuter_specific, device config files, and some of the axiliary database files (such as Localization, etc) go. They can be "shared" among applications with no issue. (new automatic updates/downloads are stored in this directory)

2) userPath is where files storing runtime information (cache file, Log files (when enabled), and Options.xml). are stored. We allow different Options.xml files in userPath as different applications might have different requirements, or to support Multiple Sticks on a single machine.

minimum requirement for the userPath is options.xml.

bwachter commented 4 years ago

I think you confused about userPath and dbPath:

Quite possible, I didn't find any documentation about those, and the code around them is not the easiest to understand.

(new automatic updates/downloads are stored in this directory)

So there are automatic updates? Which would mean the overlay I've described in the other comment would be a sensible addition for the "installed as distribution package" use case, as there won't be write support to the system wide database?

  1. userPath is where files storing runtime information (cache file, Log files (when enabled), and Options.xml). are stored. We allow different Options.xml files in userPath as different applications might have different requirements, or to support Multiple Sticks on a single machine.

minimum requirement for the userPath is options.xml.

OK, so the initial change would be to have it copy just the options.xml over in case it doesn't exist yet, and just use the system database for dbPath. I'll test that later.

Fishwaldo commented 4 years ago

So there are automatic updates? Which would mean the overlay I've described in the other comment would be a sensible addition for the "installed as distribution package" use case, as there won't be write support to the system wide database?

Previous discussions with distributions (never got anywhere unfortunately) was to install the config 0664 owned by root:dialout as OZW would need to be in the dialout group to access the serial port anyway.

OK, so the initial change would be to have it copy just the options.xml over in case it doesn't exist yet, and just use the system database for dbPath. I'll test that later.

The code has been updated. options.xml will be copied to the UserDirectory now.