From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:32770)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1dr2GP-0005qn-Gv
	for guix-patches@gnu.org; Sun, 10 Sep 2017 09:27:08 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1dr2GM-0005NA-CB
	for guix-patches@gnu.org; Sun, 10 Sep 2017 09:27:05 -0400
Received: from debbugs.gnu.org ([208.118.235.43]:49905)
	by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
	(Exim 4.71) (envelope-from <Debian-debbugs@debbugs.gnu.org>)
	id 1dr2GM-0005Mr-8O
	for guix-patches@gnu.org; Sun, 10 Sep 2017 09:27:02 -0400
Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1dr2GM-0007Ey-2e
	for guix-patches@gnu.org; Sun, 10 Sep 2017 09:27:02 -0400
Subject: [bug#27876] [PATCH v2 1/3] cuirass: Store new information in database
	to prepare new HTTP API integration.
Resent-Message-ID: <handler.27876.D27876.150505002027824@debbugs.gnu.org>
References: <20170730100759.17734-1-m.othacehe@gmail.com>
	<20170801195124.7030-1-m.othacehe@gmail.com> <87o9ql89lp.fsf@gnu.org>
	<87pob1m2bk.fsf@gmail.com> <871sngapjy.fsf@gnu.org>
	<87lglomhxo.fsf@gmail.com> <878thm907s.fsf@gnu.org>
From: Mathieu Othacehe <m.othacehe@gmail.com>
In-reply-to: <878thm907s.fsf@gnu.org>
Date: Sun, 10 Sep 2017 15:26:44 +0200
Message-ID: <87a822vg4r.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
List-Id: <guix-patches.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-patches>,
	<mailto:guix-patches-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/guix-patches/>
List-Post: <mailto:guix-patches@gnu.org>
List-Help: <mailto:guix-patches-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-patches>,
	<mailto:guix-patches-request@gnu.org?subject=subscribe>
Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org
Sender: "Guix-patches" <guix-patches-bounces+kyle=kyleam.com@gnu.org>
To: Ludovic =?UTF-8?Q?Court=C3=A8s?= <ludo@gnu.org>
Cc: 27876-done@debbugs.gnu.org


Hi Ludo,

> 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 ?

Thanks,

Mathieu