in my experience, nope, it wont. There is nothing you can do to prevent that. As evidenced by this thread and the several others, change, even the discussion of change, is like kicking an ant hill. The users become agitated and very active, some of them sting.
We just need to be prepared for it. And preparing for it will include pre-releases that those who are active on the forum can play with ahead of the release not just to find bug but to learn about how to use it and learn ahead of time those parts that might cause users problems, warning message from apt about big changes would be nice, complete docs, etc. This needs to occur before the changes appear in the snapshots I think, at least in part. As we saw with MQTT 2, once it shows up in the snapshots users will find it and start to complain. If we can get ahead of it we can write “my experience postings”, tutorials, and the like which some users will be able to find and we can direct the rest.
There was plenty of discussion and agreement from all on one of these threads that there will be some sort of migration aides developed. Kai himself also mentioned that the Xtend Rules will be ported to JSR223/NGRE so we can continue to use our existing Rules for a time at least.
Assuming everything that I’ve read that has been said on this topic gets implemented, the transition to this new version will likely be as easy or easier than than the transition from OH 1 to OH 2. That’s not to say that it won’t be completely pain free and easy. But it will be manageable.
Someone has already written a script that will port .items files to JSONDB (with some assumptions, search the forum). That script could be expanded, perhaps using some of the code in OH that already handles them. Something like that can handle the Items and Things. Rules will eventually need to be ported to NGRE/JSR223 but I don’t think that one day we will wake up and all of a sudden everything has to be changed immediately. At least I for one will be strongly pushing strongly for this.
Yet I know that Markus and I spend a good deal of time on this forum helping people deal with exactly this problem. Though the bigger problem is this combined with the file watcher queuing up the loads for multiple file changes (i.e. if you change a file and save, OH starts reloading, then change another file and save it queues up that load to occur after the current one finishes).
The issue has been open for over a year. There has been much discussion on it. There is apparently no simple fix to this. It appears to require a near complete rewrite of the file parser/loader.
I would guess it is like what I describe above. The file watcher starts loading files when it sees a file that has changed, it starts loading files, then more files change so it queues up another file load process. It all depends on timing.
But the extended load times greatly exacerbate the file load queueing problem I just described which is a more serious problem.
For some they are seeing memory leaks which have not yet been found and fixed. These users really have little choice but to restart their production OH frequently (weekly, daily).
Its most noticeable on an RPi because the files take so long to load and parse. But RPi is one of the most common platforms to deploy and it is the recommended hardware (if the user has no other preference). So if its a problem on the RPi, IMHO it is a serious problem that needs to be addresses.
I think that is exactly what is proposed with the import/export function David has been talking about.
I think at the end of the day it comes down to this. Kai and company set up OH with this central database. David is not going to sign up to change this. Kai and company who set it up like that in the first place are not going to sign up to change this.
So unless and until someone steps up to do the significant amount work necessary to restructure OH internals, this central database of serialized Java objects is fixed. It isn’t going anywhere. And any discussion about how we will move forward will have to conform to this constraint.
I will submit that David has presented a solution that conforms to this constraint. If anyone who feels strongly about changing this architecture please step up and contribute. It’s not something the current developers are willing to change at this time.
So, without a volunteer to change the underlying architecture and within the constraints of the JSONDB Java Serialized Objects, what can be done to support all the requirements we have set forth? Given these constraints, I think David is making a good faith effort to support as many use cases as possible.
This is an open source project. I don’t think it is fair to blame him for not being willing to take on a change of this type when none of us is willing to set up and do it ourselves.