[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#27876] [PATCH v2 1/3] cuirass: Store new information in database to
[bug#27876] [PATCH v2 1/3] cuirass: Store new information in database to prepare new HTTP API integration.
Sun, 10 Sep 2017 15:26:44 +0200
mu4e 0.9.18; emacs 25.2.1
> Basically, between two subsequent evaluations, 99% of the derivations
> are exactly the same (assuming an evaluation is triggered at each git
> push, and each git push adds/modifies just a handful of packages). If
> we record new builds for these 99%, even though nothing has changed,
> then that’s potentially bad, no?
Hmm, you're right but the situation is already problematic.
On each evaluation, N new entries will appear in Derivations table
(because the primary key is on derivation,evaluation tuple).
N new entries will also appear in Builds table (both with primary key on
id or on derivation,evaluation,output tuple).
When build start/stop will be detected, only a small part of N
(derivations which were rebuilt), will be added to Builds. Checking for
pre-existing builds with the same derivation will become useless unless
So there's still the problem of Derivations table growing from N at each
commit. I'm not sure what to do about it. Maybe removing the
"evaluation" field, and puting primary key on "derivation" only would be