From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Cl=C3=A9ment?= Lassieur Subject: bug#32300: [PATCH] database: Fix the builds limit issue. Date: Thu, 09 Aug 2018 10:02:47 +0200 Message-ID: <87k1p0otlk.fsf@lassieur.org> References: <874lgjc5g9.fsf@lassieur.org> <20180804160057.20254-1-clement@lassieur.org> <87sh3ui038.fsf@lassieur.org> <20180809075709.44883c92@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53437) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fnfuV-0003VS-AV for bug-guix@gnu.org; Thu, 09 Aug 2018 04:03:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fnfuS-0002CG-7l for bug-guix@gnu.org; Thu, 09 Aug 2018 04:03:07 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:40493) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fnfuS-0002CA-2q for bug-guix@gnu.org; Thu, 09 Aug 2018 04:03:04 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fnfuQ-0001kb-99 for bug-guix@gnu.org; Thu, 09 Aug 2018 04:03:03 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <20180809075709.44883c92@scratchpost.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Danny Milosavljevic Cc: 32300@debbugs.gnu.org Danny Milosavljevic writes: > Hi, > > On Sat, 04 Aug 2018 18:10:51 +0200 > Cl=C3=A9ment Lassieur wrote: > >> Cl=C3=A9ment Lassieur writes: >>=20 >> > Fixes . >> > >> > * src/cuirass/database.scm (filters->order): New procedure. >> > (db-get-builds): Remove FORMAT-OUTPUT, CONS-OUTPUT, COLLECT-OUTPUTS, >> > FINISH-GROUP, SAME-GROUP?, GROUP-OUTPUTS procedures. Remove the 'LEFT= JOIN >> > Outputs' clause. Use DB-GET-OUTPUTS for each build that was fetched.= =20=20 >>=20 >> This may be less efficient because there are more SQL queries (one per >> output), but it's way less complicated and less buggy, so I think it's >> worth it. > > Yeah, if it's still usable, I agree. > > But I think we shouldn't overlook the possibility of not fetching the out= puts > in the first place (at all). I totally agree! Although it should be another commit, I think.