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
PRs #1655, #1656, and #1657 added foreign keys to many of CDash's tables, helping to protect our data integrity & make sure that old data gets deleted automatically when it is no longer referenced.
I audited the rest of CDash's tables and came up with the following list of recommendations.
Unused tables we could probably drop without impacting existing functionality
label -- this one seems tricky, we would have to check every label2* table.
note (build2note.noteid)
repositories (project2repositories.repositoryid)
site (build.siteid)
test (build2test.testid and/or testoutput.testid)
testoutput (build2test.outputid)
uploadfile (build2uploadfile.fileid)
Many of these tables are already being handled through clever queries in remove_builds() but if a row somehow "slips through the cracks" it currently requires manual intervention to delete it later on.
Functionality to more generally reconsider:
coveragefile2user -- this association seems tied to a particular version of a source file, I'm not sure that's actually useful?
dailyupdatefile -- we might not need this at all anymore since we dropped the "feed" a while back?
The text was updated successfully, but these errors were encountered:
It's worth noting that some tables like the banner table contain "global" rows (using the project ID 0, for example), which makes it more difficult than it initially appears.
Great work putting together this list though! I'll gradually work though it as I have time.
This PR adds a foreign-key constraint to the `dynamicanalysisdefect`
table, as well as associated indexing, in support of #2093. Dynamic
analysis results are now cleaned up 100% automatically when their
associated build results are removed.
Feature Request
How can we make CDash better?
PRs #1655, #1656, and #1657 added foreign keys to many of CDash's tables, helping to protect our data integrity & make sure that old data gets deleted automatically when it is no longer referenced.
I audited the rest of CDash's tables and came up with the following list of recommendations.
Unused tables we could probably drop without impacting existing functionality
Tables that would benefit from foreign keys
Tables whose rows contain a timestamp that could be used for periodic deletion
It's worth noting here that the following tables are already cleaned up in
addDailyChanges()
:Shared data that could be deleted by periodic
NOT IN (...)
queries:Many of these tables are already being handled through clever queries in
remove_builds()
but if a row somehow "slips through the cracks" it currently requires manual intervention to delete it later on.Functionality to more generally reconsider:
The text was updated successfully, but these errors were encountered: