Maybe limit it to 1 week worth of events total. For those who wants more, they can setup InfluxDB.
Like I said, adding a date to it makes the query extremely complex and even more time consuming to execute, it's also not a high priority at this time.
The solution to database bloat is to use device drivers that only produce relevent events...
Events are for automations, they are not just some handy location to dump whatever you want.
Sonos driver is built in. It is beyond verbose. Why do I need to know the volume 12 months ago?
Please limit to 1000 total. Simple.
But even so... if relevant events hang around forever then that is still going to result in bloat eventually yeah?
here's how many entries i have on the weather driver. Clearly there need to be some publish guideline on this or else my DB will just keeping growing forever?
It isn't that simple, and i seriously dont have the time to explain why.
I've given you all simple ways of understanding and managing these things. In the end the actual size of the database is of little consequence, and with the exception of application calls for event history, does not impact system response.
Creation of excessive events that are of no use does impact system performance, and establishing some lower count threshold for the reqular cleanup job does not in any way prevent these events from collecting throughout the day.
Every single event attribute change value is a write to the database...
Why would you write to a database unless you needed to?, you only write items you intend to use.
This hub is not an enterprise class warehouse RDBMS...
Mike, the driver I'm referring (Sonos) is built in. It's written by you guys. I didnt write the driver.
I didn't make any comments about that driver.
I was wrong about how we select the 1k events to keep. It is simply attribute name not name and value pair. Haven't worked on that section of code for almost 2 years...
So the pruning should be keeping 1000 entries for each attribute?? So 1000 for Motion, 1000 for lux, 1000 for temp for example?
Correct
Gotcha. That at least gives an idea of how many should be there if we think the maintenance job for whatever reason isn't doing its thing. It probably would be good to have that number as a user configurable hub setting somewhere, as a 1000 seems quite a lot really, for each attribute.
I suppose it would be more useful for some attributes over others though.
