* Drop violating rows before adding foreign constraints
* Don't delete rows with null-references
* Only delete rows when integrityerror is caught
* Move restore of dropped foreign key constraints to a separate migration step
* Use aliases for tables
* Update homeassistant/components/recorder/migration.py
* Update test
* Don't use alias for table we're deleting from, improve test
* Fix MySQL
* Update instead of deleting in case of self references
* Improve log messages
* Batch updates
* Add workaround for unsupported LIMIT in PostgreSQL
* Simplify
---------
Co-authored-by: J. Nick Koston <nick@koston.org>
* Ensure legacy event foreign key is removed from the states table
If the system ran out of disk space removing the FK, it would
fail. #121938 fixed that to try again, however that PR was made
ineffective by #122069 since it will never reach the check.
To solve this, the migration version is incremented to 2, and
the migration is no longer marked as done unless the rebuild
/fk removal is successful.
* fix logic for mysql
* fix test
* asserts
* coverage
* coverage
* narrow test
* fixes
* split tests
* should have skipped
* fixture must be used
* Refactor recorder data migration
* Fix stale docstrings
* Don't store a session object in BaseRunTimeMigration instances
* Simplify logic in EntityIDMigration.migration_done
* Fix tests
* Narrow sqlite database corruption check to ensure disk image is malformed
The database corruption check would also replace the database when it
locked externally instead of only when its malformed.
This was discovered in https://github.com/home-assistant/core/issues/121909#issuecomment-2227409124
when a user did a manual index creation while HA was online
* tweak
* tweak
* fix
* fix
* Ensure states table rebuild still happens if the event_id index was removed
If ix_states_event_id was removed by the foreign key still
exists, the states table would not get rebuilt. This should
not happen under normal circumstances and seems to only be
possible if the index was removed manually or Home
Assistant was restarted forcefully in the middle
of a previous migration from years ago.
* cover
* fix tests
* mysql wont allow at that point but thats ok as long as its gone at the end
* Add test fixture to control recorder migration
* Update tests/components/recorder/conftest.py
Co-authored-by: J. Nick Koston <nick@koston.org>
* Update tests/components/recorder/conftest.py
---------
Co-authored-by: J. Nick Koston <nick@koston.org>
Erik Montnemery
J. Nick Koston
Marc Mueller
epenet