Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0B42367 for ; Fri, 23 Oct 2015 06:53:28 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from server3 (server3.include7.ch [144.76.194.38]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 5B185EB for ; Fri, 23 Oct 2015 06:53:27 +0000 (UTC) Received: by server3 (Postfix, from userid 115) id 20ECC2E601C1; Fri, 23 Oct 2015 08:53:26 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1 autolearn=ham version=3.3.1 Received: from Jonass-MacBook-Pro.local (cable-static-140-182.teleport.ch [87.102.140.182]) by server3 (Postfix) with ESMTPSA id 60D462D002B3; Fri, 23 Oct 2015 08:53:24 +0200 (CEST) To: Jeff Garzik , Bitcoin development mailing list References: From: Jonas Schnelli X-Enigmail-Draft-Status: N1110 Message-ID: <5629D960.8060109@jonasschnelli.ch> Date: Fri, 23 Oct 2015 08:53:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 23 Oct 2015 08:22:10 +0000 Subject: Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 06:53:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Here is the beginnings of an implementation to replace leveldb > with sqlite: https://github.com/jgarzik/bitcoin/tree/2015_sqlite > > It builds, but still needs work before passing tests. Nice work! Although not sure if we should focus directly on sqlite4 (could be optional with a configure flag and a subtree [until stable], sqlite3 supported over depends). Also i personally would recommend to not implement it as a replacement, instead, support multiple backends (wrapper header / different wrapper implementations [leveldb / sqlite3 / sqlite4]). But – agreed – should not be the focus, but a nice additional flexibility if it not require much more work. And – in theory – multiple database back-ends would allow migration. Before investigating to deep, i think we need a dbwrapper bench tool that represents our needs and our style how we hit the database. Gavins recently added bench target / bench environment could be used for that. /jonas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWKdlgAAoJECnUvLZBb1Ps7J8P/2L6215fd0rWGv5uvbLSnQvm hy1T2AaOfH5HXd2m95icaKYk+ugvQAL80Q/67YwZbPLsT4fErgegw8n75Z6nh/Pc OJ1EtAvD+Kc/Vm0Wcvt421HXwnm4f+j+8eoEvpG6DdC8gfIG+efhM7DljeNbPFrA ieNe7XrQ1EZ29lMzpQv0nx3bi6tUHOWuazk82B6vnK49MjH7nrUFipcc18nXbSpM ZKjQakXmfqIBG8QP9ZUYUlW4aoG0oaOoZnGjQA2LeXBJpIPLpE/WPg0XaXubC+No 232CJNtNyUOmjkb2qbep6vSYgqGJNy1HbCU5y3qooxJhFnKdo63CQsyJKSpL/ssi 0lWraNxjbacxsBn+63In3wEkj02orwm2zTO4I77wCrZmJgpvBFb9bZWTeL8DCYSG DTkZoKWEK74xvm+dNpEWXK9Lm1ltfyhPdaFeMoRDub4w2uuYlk3KuD8Vdy81HYJb sak8FbkiWw9xx2OP9+G56Arf9W6mnJ3YHJGrY4SXeRAfuNYwGFHIGt6I1JobuHy4 VWmcHuooz/Q9JLUu3Rr3HsEdXYgCmgmWuzTgWG+Hx92Y6XLWV5pOX+vFRO6J5fSm aTYPD4GsTM3FROXw5ezlXJ+2y1+ITzmrfm03fEDQvoIyH0TwBqBc5sMBBkma5DDR 0HUthPHWCD+AxbBPbRVa =CUMX -----END PGP SIGNATURE-----