[Top][All Lists]

[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

From: Ludovic Courtès
Subject: [bug#27876] [PATCH v2 1/3] cuirass: Store new information in database to prepare new HTTP API integration.
Date: Sun, 10 Sep 2017 22:38:59 +0200
User-agent: 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.

Future work!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]