Would it be possible to backup the userdata folder as a whole and overwrite the userdata folder that comes with the distribution?
Well, in general a full backup comprises the conf and the userdata folder, that’s the idea. Note that the distribution does not come with any userdata folder at all, so this does not get overwritten either.
That is, if a thing is setup in a textual file, it should be taken as it is defined and Paper UI should not discover a new copy of this thing.
But should it also not be possible for the Paper UI to edit the Thing? Or have a binding add dynamically properties to it, which it read from the device (e.g. the Tesla binding adds the info that you have a sunroof)?
Currently, if I am right, you will have two instances for the same thing in this case ?
No, it a thing with the same UID already exists (being defined in a things-file), you will not see it in the inbox.
let the Ui edit those files. So you can make changes within the Ui and in the text files.
There are a few reasons against this:
- the
conf folder is meant to be read-only and only the system admin should have write-access to it. This is something I would want to keep, because if you open it up for the runtime to access it, the user has no idea of what stuff is changed in there without his knowledge. Well, we could say that the runtime copies this stuff to userdata and edits it there, so it would be a kind of import mechanism for static files.
- The current files are parsed through Xtext. While I agree that the Designer is meant to be a nice tool, I also see that most people are actually using vi or emacs instead. And having Xtext as a part of the runtime has the problem that it is quite heavy purely for handling configuration files and that there do not seem to be people in the openHAB community, who can deal with it, so that simple bugs stay open forever. For these reasons, I would only want to keep the existing files and their infrastructure for OH1 compatibility, but not really build on top of it to also allow editing them through Xtext (what Xtext in general supports).
- Not using Xtext for writing files would probably mean that a lot of formatting, comments, etc. get lost within the files.
- The Xtext files are not meant to be a “db replacement”. Doing edit operations through the REST API can cause quite some heavy db activity as it is not done as bulk, but in many small transactions. Even the MapDB implementation seems to be sometimes too slow to handle it properly on a RasPi.
- By far not all configuration is handled through openHAB/Xtext itself. If you install a new Karaf feature on the console, there is no way to have that serialized into the “addons.cfg”. Likewise all changes about logging configuration or other services. You can do a hell of a lot in Karaf and all such settings are stored somewhere in the OSGi internals according to good OSGi manners…
For these reasons, I think the best approach is to go with the possibility of having the “old” files as a kind of import and treating the database as THE point of reference.
I think it will be possible though to replace mapdb with an XML version.
Yes, ESH allows plugging in different storage implementations. We are actually serializing all stuff to JSON, so this would be my preferred format.
But you need to be aware that you will end up implementing a complete database - with consistency checks, recovery, internal caches, indexes, query optimizations, etc. I am not too sure that this is the way to go.
An alternative might be to accept the binary (and thus efficient) format of MapDB and rather provide an “export to text” mechanism. This could be e.g. triggered automatically once in a while or upon a “backup” request.
FTR, you might also want to read this discussion here: Eclipse Community Forums: Eclipse SmartHome » Dynamically created Channels during initialize()
)
)