[DBCleaner] Clean old versions

[DBCleaner] Clean old versions

  
Forge Component
(28)
Published on 16 Aug by Mika Roivainen
28 votes
Published on 16 Aug by Mika Roivainen

Hi DBcleaner Master


i want to use CleanOldESpaceVersions timer to clean my old espaces, but i am not sure what this timer done exactly. Is cleaning all espaces older than 8 weeks? if an espace has only versions older than 8 weeks keeps only one version of the espace?

Can you provide us more documentation please?


Thanks

Matheos

Hi Matheos

Tagged versions i.e. when you deploy from dev to test or test to production, will not be deleted.

Hanno


Hi Hanno,


I ma not sure if i understand your answer. You mean that all versions i moved from dev to test will not be deleted? How the platform knows this information?


Thanks 

Matheos

Hello Matheos,

Don't know which time it set for that timer, but if it's 8 week, it will delete all eSpaces versions older than 8 weeks, also it it's the last version.

Hanno, I don't think so. The timer deletes all eSpace version older than x time. When you have deployed a version to your next environment it will exist on that environment as a version for that eSpace (test/prod would have much less versions by this). But there is no relation between an espace in dev to test.

This component is an old version, nowdays OS has a DBCleanerAPI module that you can reference from service studio.


Kind regards,

Evert

Hi Evert

In LifeTime, when you view the version history of an application, it displays the tagged version, i.e. the versions that were used for a deployment to another environment (like dev to test). Those versions are the ones not deleted as they have related entries elsewhere in the database.

Regards
Hanno


I could be wrong, but the version history (LifeTime) are still environment specific. LifeTime has tables which contains the data of which version is on which environment (I thought based on the eSpace identification guid). So on the environment itself you can delete eSpace versions that could be in a tagged version in OutSystems. LifeTime is the connecting application between the environements. 

When you do a deploy OS is building a solution and publish that solution into the next environment. Solutions aren't connected to each other, so a dev eSapce version isn't (physical) connected to a tst eSpace version.


Kind regards,
Evert

Hi Evert

Perhaps this will shed more light? 

"This means that some internal tables which are not exposed cannot be used to exclude some espace versions that are locked by being tagged in LifeTime."

Hanno

Hello Hanno,

I know that problem, but also know what is causing that problem. The error mentioned in that post isn't an internal table (if I can belive OS support (have supportcase about it right now)). It the same eSpace table that has 2 links to the eSpace version table where one of that links is protected.

Beside that I know about system tables which you can't see, but still there is no (physical) connection between an eSpace on 2 different environments.LifeTime keeps that data about which version is deployed where, in system tables (lifetime). There you also can find the deployment logs, from older versions.

Still have to do the supportcase options, then I can exclude if versions are really used by lifetime or not (-:

Kind regards,
Evert

To come back on our discussion, the answer of support:


So there is a difference on how this component works vs the API provided by OS.


Kind regards,
Evert