You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have some apps that track a fair amount of very granular activity, but it's not clear that there is much value in saving this data indefinitely at the cost of having the xh_track table rowcount increase in an unbounded way.
We should add a configurable option to have the server delete activity data older than a certain number of days. If enabled, this routine could be run once a day via a timer in TrackService.
Default value is up for discussion - safest is probably to have it disabled by default (although one could argue that having some limit on track entry storage is "safer" in another way). We could check with our clients before enabling, but could aim to make setting to something like 365 days a best practice.
The text was updated successfully, but these errors were encountered:
We would also want to do some testing to ensure that an app that had a very large track table ran its deletes in some managed fashion after release. E.g. assuming the delete routine runs daily or every n hours on a timer, we could set a limit to how many logs could be deleted at once. It might then take a while for an app to "prune back" to its configured limit, but we would avoid a potential database/replication storm of some kind triggered by deleting 2m rows in one shot...
We have some apps that track a fair amount of very granular activity, but it's not clear that there is much value in saving this data indefinitely at the cost of having the
xh_track
table rowcount increase in an unbounded way.We should add a configurable option to have the server delete activity data older than a certain number of days. If enabled, this routine could be run once a day via a timer in
TrackService
.Default value is up for discussion - safest is probably to have it disabled by default (although one could argue that having some limit on track entry storage is "safer" in another way). We could check with our clients before enabling, but could aim to make setting to something like 365 days a best practice.
The text was updated successfully, but these errors were encountered: