-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor config entry storage and index #107590
Conversation
Refactors config entry storage to work the same as the entity registry and the device registry. This abstracts all the maintaining of the index into the ConfigEntryItems class. We now have an index for the unique id as well since this each discovery will have to lookup to see if the unique id already exists. This starts to be a problem when the a device is discovered frequently. An example case of this is when the user has a lot of ESPHome devices and deep sleep configured. This means devices are constantly being rediscovered and since there was previously no index on unique id, it meant all the config entries in the domain had to be enumerated every time a device woke up
running well on my system for a bit. solves the constant unique id lookup from discovery churn issue |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks nice! Some minor ideas, but not required.
Thanks |
Well all the test failure are bugs in the tests. I'm going to make it |
I will fix them all in a separate PRs |
I fixed the duplicate adds in everything but plex and zha in #107984 plex and zha will need their own PRs as their logic is a bit more complex |
needs test fixes
Proposed change
Refactors config entry storage to work the same as the entity registry and the device registry. This abstracts all the maintaining of the index into the ConfigEntryItems class.
We now have an index for the unique id as well since this each discovery will have to lookup to see if the unique id already exists. This starts to be a problem when the a device is discovered frequently. An example case of this is when the user has a lot of ESPHome devices and deep sleep configured. This means devices are constantly being rediscovered and since there was previously no index on unique id, it meant all the config entries in the domain had to be enumerated every time a device woke up. In this case we would have actually had to enumerate the whole list twice, with once for
async_set_unique_id
and once for_abort_if_unique_id_configured
Type of change
Additional information
Checklist
ruff format homeassistant tests
)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest
.requirements_all.txt
.Updated by running
python3 -m script.gen_requirements_all
..coveragerc
.To help with the load of incoming pull requests: