<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 11, 2016 at 7:46 AM, Matějů Miroslav, Ing. <span dir="ltr"><<a href="mailto:Mateju.Miroslav@azd.cz" target="_blank">Mateju.Miroslav@azd.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I have discovered duplicate rows in the build2test table which is the biggest table in my CDash database. The query<br>
    SELECT `buildid`, `testid`, COUNT(`buildid`) c FROM `build2test` GROUP BY `buildid`, `testid` HAVING c > 1 ORDER BY c DESC;<br>
returned many entries with the highest reported count of 11. Shouldn't the pair buildid + testid be unique? I tried to check data of a few reported entries and all the rows appeared to have same values in all columns.<br></blockquote><div><br></div><div>I think you're right that a unique constraint would be appropriate here.  I'll run some experiments to see what the resulting Test.xml file looks like when using ctest's <font face="monospace, monospace">--repeat-until-fail</font> command-line option.  That's the only potential case I can think of where it might make sense for a single build to contain multiple copies of the same test(s).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
The duplicates may come from a wrongly configured submission processing: The default CDASH_SUBMISSION_PROCESSING_TIME_LIMIT was too low and CDash tried to asynchronously process big submissions again and again. However, the duplication could be prevented most likely if the table had a PRIMARY KEY (or UNIQUE constraint) defined. Currently it has none.<br></blockquote><div><br></div><div>You're probably right.  If the same Test.xml gets processed more than once, then you'll likely end up with duplicate rows in build2test (as you are experiencing).</div><div><br></div><div>Another way this could occur is if you're running the same Nightly build multiple times per day.  CDash used to automatically delete a nightly build when a new one with the same name and timestamp was received.</div><div><br></div><div>This was a headache for parallel submission processing, so instead you now have to mark such a build as 'done' for it to automatically be removed when a new copy is submitted.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Could you recommend any actions I could perform? Is the best to let Autoremove take care of it (which is currently disabled in my case)?<br></blockquote><div><br></div><div>Auto-remove will certainly help keep your database from growing without bounds.  If you're feeling adventurous, you could experiment with a unique constraint on the build2test table.  Otherwise I'll try to look into this as time permits.</div></div></div></div>