Looking at the release notes for 2023.4, there appears to be a major breaking change that isn’t really called out. Given that the recorder schema is changed and all the data migrated to the new schema, is it actually possible for a normal user (i.e. not a tech wizard) to revert to 2023.3 in the event of a problem?
Reverting schema changes isn’t supported. What’s broken for you? We might be able to work out a solution.
Yes, if you are happy to delete your database.
Or have a backup.
Don’t think that a backup includes a database dump, at least I don’t see any indication when “untaring” the files in a backup.
Nothing’s broken for me. I’m just thinking of the wider community of users: not all of whom are experts in this stuff.
Breaking things has always been a core philosophy of this project, but sometimes it’s done in an uncaring way (IMO). Like I said in the OP, needing to delete the database and lose some history is not a major problem for me, but for the naive user?? Would they get adequate error messages and diagnostics to guide them? Did the developers actually try to downgrade?
I just wanted to confirm that this is a breaking change, and to suggest that this be made a bit more prominent than it currently is in the release notes.
As for me, I’ll adopt my usual approach - never install a .0 release; wait for at least one round of bug fixes.
1 Like
I upgraded an didn’t loose old data.
Also if they try to make things better and there are some side effects, then I am ok with that. The db optimization is always welcomed, specially in Raspberry Pi or slow equipment.
The OP makes an excellent point. There is no “downgrade” path which would preserve all the recorder data collected since the upgrade. I believe the backup does include the database, so really all that’s lost is the data collected between the backup and the downgrade. That should be a time of testing and verifying, but of course there will be problems which aren’t immediately noticeable. Not a big deal for me (I don’t really count on the Recorder data for much) but it does deserve a mention in the breaking changes.
It really helps to have a test-system on which you can test the betas. I’m always sure I can upgrade (or not), because I report all issues I have with the beta.
The database gets runtime data. Interesting from a historical point of view, but not essential. You can clear it and start from scratch.
I know it’s ephemeral data, as do you. My point is that ANY non-reversible upgrade should be signaled very clearly to users.
If HA is ever to become a mainstream product rather than a hobbyist plaything, in my view, it needs to be a lot more rigorous about breaking changes. The casual user knows nothing, and cares less. They just want something that works for their environment.
I’ve made this same observation before, but I’ve come to realize that I started with a false assumption.
HA is and will forever be a hobbyist plaything. To be honest, one reason I chose HA was because of the very active development and the volume of activity seen here on this forum.
With that comes some down side. First there’s the steep learning curve to accomplish even the most basic tasks. Then there are the constant changes, all of which assume you’ve already mastered the learning curve. Finally, there’s the fact that, like any open-source project, changes are made at the whim of the developers. A classic example is all the UI changes being made to “dumb down” the interface and make it look more trendy. Some of these provide no value to existing users, but look great on the developer’s resume.
This is what we signed up for. The alternative is to buy an off-the-shelf, propriety system and be locked into that vendor’s cloud ecosystem. Given that choice, I’ll probably stick around.
Fellas this was not well done. I just upgraded and lost almost two years of historical data. Had I known there were breaking changes and that there is absolutely no rollback path, I would have done the backup myself. Yes, technically I’m the stupid one for assuming, that the migration would involve taking a db dump and storing it somewhere. But this was very poorly handled…
First of all, I feel your frustration. A loss of data like that is aggravating.
That said, you are also correct that it’s kind of on you to decide how to back up and protect the data which are important to you. HA assumes a certain level of understanding about how these things work.
Unfortunately I can’t help recover your data. I can only offer my own perspective, and maybe it’ll help you plan your overall strategy.
Basically, forget about using the HA database for archival data. Yeah, I know, the dev’s went to great trouble to add all those new statistics tables. And they do capture a lot of historical data better than the original events and states tables. The problem is, dynamic and archival data have different performance and retention requirements. IMHO, they don’t really belong in the same database.
And again, with respect to all the great work which has gone into developing the UI tools in HA to display all that archival data, this isn’t what HA was designed for. There are far better data analysis tools out there. For me, just storing the data I want to keep in .csv files and opening them in Excel or Access (or their LibreOffice equivalents) is far more efficient and effective. I know some HA users are more into data analysis than I and use even more advanced tools, outside of the HA UI.
1 Like