Routine Purging of Call Log Data?

[whitedavidp]

While I am still very new to this so this is no problem for me now. But it seems that over time, the call log data really might get voluminous and/or out of date. As such, I wonder about a configuration item that specifies a retention period (perhaps in days) for the call log data and a mechanism (perhaps executed at startup time) to remove any data older than the specified number of days?

Seems like this SQL would do the trick:

delete from CallLog where SystemDateTime < DATETIME('now', '-xx day')

[thess]

Or... You could write a shell script to do this and set it up as a CRON job under the same account running CA. More flexible approach and not necessary to complicate the main application with task scheduling.

[whitedavidp]

That could sure work. But I wasnt thinking any real scheduling. Just at startup, if the configured days isnt zero (for never clean the data), simply execute the above sql.

[thess]

I thought you might say that. However, with my permanent installation, startup only occurs after a power fail or system upgrade. It could be many months between "startups".

[whitedavidp]

And mine gets rebooted every night as part of a backup scheme :-)

[roycewilliams]

The sqlite command line is pretty learn-able - and you can copy the db file, and experiment with the copy.

For semi-related reference, here's the clunky script I use to dump some tables to CSV:

https://github.com/roycewilliams/callattendant-resources/blob/main/db-to-csv.sh

A "DELETE FROM [tablename] WHERE [condition]" should be relatively easy to script.

[whitedavidp]

Thanks. Yes, the sql is easy, that is why I was able to write and test it above...

I guess I am just not sure who the target audience is. Obviously, users must know enough to install and configure. But requiring everyone to read the db schema, figure out the right sql to execute, and figure out how they want to trigger it seems way above many people and essentially re-creates the wheel over and over.

Maybe there should just be a script including in the bin folder and folks can execute it if/when they want.

Or, we can forget the whole thing and I will just modify my version...

Best

[roycewilliams]

I definitely see the appeal in having something canned. If it doesn't fit in the 'core' callattendant repo, we could stash it in my -resources repo so that others can benefit from it.

[whitedavidp]

I guess I might be able to use a similar script to clean up another thing I would like to accomplish: getting rid of callers permitted by virtue of having pressed the correct button during screening (and who never called back - at least within some reasonable time frame - a day even seems too long but I am not sure what would be more correct). These would seem, by definition, to be bogus permitted callers that we really don't want sitting around in that state. Since there is a known reason text in the database for these entries, I suspect that a query can be developed to clean them up.