For some time we in our project were wondering why are we losing modules history, until someone pointed that it's DBCleaner doing it. In dev environments, this history is the most important thing which you have, more important than any data in your entities, so you can't just have a timer to automatically clean it! This thing should be manual or require an action to turn it on.
We had DBCleaner installed for ages, and I personally was sure that it's purpose is only to clean old fields from the tables, and never actually had to use it. It could be that the person who installed it didn't read notes, or didn't care, or maybe this feature was not there at that time. And now we are not able to see what changes were done 2 months ago.
First of all the Clean-timers aren't scheduled by default, so this must have been done by the person who installed it. Secondly the timer doesn't delete module versions from tagged application automatically: you need to that manually (tab Applications). Do you really need ALL the module versions after 2 months?
Thank you for explaining, Ralph. Yes I see now that the timer doesn't have schedule by default, so somebody should have set it up manually. Regarding "doesn't delete automatically", I didn't see it in code, it looks like the timer does exactly the same and even more than the link in "Applications"... but I trust that you know it better.
Regarding your last question - yes, off course, we have big commercial project and ideally we need all versions available forever. Off course if there is space limitation or it's impossible for some other reason - different thing. 2 month is nothing, we have release every month or two, which means we lose version from the previous or pre-previous release.
Now I'm curious, how does it work that it deletes versions 2 months old, but keeps versions about a year old?
Actually, I think the Applications page is not about that. There are "eSpace versions" and "eSpace version list" pages, which show those versions which I mean. And they don't have manual action. So yea, I believe the timer does delete them automatically.
Yes, it does it, and shows log in history
For some reason I didn't receive the responses from your side. I'm not sure tou are still interested in my answer.
I meant that espaceversions (modules) that are part of a tagged application version are not delete automatically by the timers. This means that moduleversions that have been promoted to a next environment as part of an application won't be deleted. Effectively meaning that moduleversions of 2 months old can be deleted, while other module versions older than a year are preserved.
Although it might be that you are/were using an older version of dbcleaner, because I don't have the lists "eSpace versions" and "eSpace version list" in my version, but "Module Version List" and "Module CleanUp". At least the latest version of Db Cleaner excludes espace versions part of tagged applications !
In our case we have a release every three weeks, but have all the released versions available from the beginning. We rely on a process in a CI/CD pipeline in which we remove after a release to production all intermediate application versions between the current and previous production release. Then we rely on the timer of dbcleaner (or in our case "Db Cleaner on Steriods") to delete the espace versions of those applications after 2 months. This way we have all production versions available, but aren't bothered by all kind of intermediate versions that only made it to test.
We use the version of "Db Cleaner on Steriods" (Timer PruneAll_SpaceVersions) because it does a more thorrow delete of metadata from the OutSystems repository (like site properties, timers, entities etc).