From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexandre Garreau Newsgroups: gmane.emacs.devel Subject: Re: sqlite3 Date: Thu, 09 Dec 2021 08:05:27 +0100 Message-ID: <2176540.5f6G0mJ9Du@galex-713.eu> References: <87tufmjyai.fsf@gnus.org> <2F63580E-FF58-45D0-9DBB-389ED64C0F11@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3655"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 09 08:06:30 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mvDVd-0000o8-SH for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Dec 2021 08:06:29 +0100 Original-Received: from localhost ([::1]:44118 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mvDVc-0006z7-3V for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Dec 2021 02:06:28 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36314) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvDUk-0006E5-N8 for emacs-devel@gnu.org; Thu, 09 Dec 2021 02:05:35 -0500 Original-Received: from [2a00:5884:8305::1] (port=36392 helo=galex-713.eu) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvDUi-0005vk-W9 for emacs-devel@gnu.org; Thu, 09 Dec 2021 02:05:34 -0500 Original-Received: from gal by galex-713.eu with local (Exim 4.94.2) (envelope-from ) id 1mvDUd-000Iok-PA for emacs-devel@gnu.org; Thu, 09 Dec 2021 08:05:28 +0100 In-Reply-To: <2F63580E-FF58-45D0-9DBB-389ED64C0F11@mit.edu> X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:5884:8305::1 (failed) Received-SPF: pass client-ip=2a00:5884:8305::1; envelope-from=galex-713@galex-713.eu; helo=galex-713.eu X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:281445 Archived-At: Le merkredo, 8-a de decembro 2021, 6-a horo kaj 41:17 CET Qiantan Hong a=20 =C3=A9crit : > 3. Database files are not readable directly by a text editor. Well, if we start supporting sqlite, emacs might become such an editor! =20 Imagine if when you opened a binary sqlite3 database emacs offered you the= =20 database, with many elisp commands to edit it by hand? think like=20 phpmyadmin, but lighter > 4. SQLite3 is an additional dependency. I hear people saying one > can make it optional, but I highly doubt if people are willing > to maintain 2 version of code with/without SQLite3, especially > after they starts to write SQL instead of Elisp. Exactly, so to make that safe we ought to make a standard abstraction over= =20 sqlite, that encompass some alternatives. > 5. Database is essential for manipulating trillions of records, > but that's not a typical use case of Emacs. It provides little > benefit if data fits into main memory. We could see new usages of emacs, replacing more other programs with the=20 emacs way, or replacing *better* programs emacs (that is, Lars, through=20 emacs) is already trying to replace, such as MUA (gnus, rmail), and=20 browsers (eww). > Some other alternative ((g)dbm, recutils) is free from some of > those problem, but I think the following option is the best overall: >=20 > 1. Implement a persistent key/value store or object store in > plain Emacs Lisp. I posted an implementation in anther thread > titled "Against sqlite3!!! (Was: sqlite3)" Weren=E2=80=99t there some error about using load instead of more safely re= ading=20 file content? > 2. I highly doubt if LISP is in any case insufficient for querying. > But in those case, embeding a Prolog implementation in Emacs > Lisp is a much better option than SQL. To me prolog is a little overkill, and sql slightly more readable and=20 practical to query complex values. If you want something almost as=20 practical but simpler, there=E2=80=99s also SparQL, which is used by WikiDa= ta and=20 comes from the semantic/xml/rdf world. However, one could just as well reimplement SQL into emacs, starting with=20 a naive implementation that just do what=E2=80=99s asked, without formidabl= e=20 optimisation. If anyone did that, we could even use that on top of gdbm=20 and unintentionally end up with a not undecent lisp database=E2=80=A6 And = that=20 could be used as a even higher sql-ish, yet lisp, abstraction to (efficient= =20 or not) databases.