From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: Cuirass news Date: Fri, 9 Feb 2018 12:29:31 +0100 Message-ID: <20180209122931.5a47e63e@scratchpost.org> References: <877es6x5xj.fsf@gnu.org> <87lggmjjgo.fsf@gmail.com> <87k1w6jjak.fsf@gmail.com> <87h8raxeym.fsf@gnu.org> <20180126153005.259a75e8@scratchpost.org> <87zi4z1eb0.fsf@gnu.org> <20180127181852.42f0bcbf@scratchpost.org> <87fu6bwqix.fsf@gnu.org> <20180208172905.19e9e789@scratchpost.org> <871shvt94p.fsf@gnu.org> <20180209000526.5b9ea8e7@scratchpost.org> <87wozm4i12.fsf@gnu.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]:45808) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ek6sA-0007oe-7m for guix-devel@gnu.org; Fri, 09 Feb 2018 06:29:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ek6s5-0006NF-Ar for guix-devel@gnu.org; Fri, 09 Feb 2018 06:29:42 -0500 In-Reply-To: <87wozm4i12.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?ISO-8859-1?Q?Court=E8s?= Cc: guix-devel Hi Ludo, On Fri, 09 Feb 2018 10:41:13 +0100 ludo@gnu.org (Ludovic Court=C3=A8s) wrote: > Yes. Also, in practice, everyone=E2=80=99s going to make the same /api/* > requests (because there are only two clients, the Emacs and the Web UI, > and they typically always do the same requests), which in turn means > we=E2=80=99ll always get the same =E2=80=98db-get-builds=E2=80=99 call, p= ossibly with just a > different limit, but it=E2=80=99s still the same statement. > So I think we should be fine. Right. > >> Indeed! Should we change =E2=80=98sqlite-finalize=E2=80=99 to a noop = when called on a > >> cached statement? (Otherwise users would have to keep track of whether > >> or not a statement is cached.) =20 > > > > Hmm maybe that's a good way. But its a little magic. =20 >=20 > Yes, but I think we have no other option: now that caching is built into > sqlite3.scm, it has to be properly handled by all of that module. For > the user, it should be a simple matter of choosing #:cache? #t > or #:cache? #f, and then (sqlite3) should just DTRT. Yeah, but then let's add sqlite-uncache or something that can be used to remove it from the cache after all. And make sqlite-finalize a noop if it's cached. Sounds good. So a savvy user could do sqlite-uncache and then sqlite-finalize and it wou= ld be gone.