[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 22:38:59 +0200
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
Mathieu Othacehe <address@hidden> skribis:
>> 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
> I'm wrong.
> 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
> better ?
You’re right, I don’t know off the top of my head. Perhaps we should
check the schemas that Hydra uses, it should be similar.