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 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: