From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Jose E. Marchesi" Newsgroups: gmane.emacs.devel Subject: Re: sqlite3 Date: Tue, 07 Dec 2021 04:44:43 +0100 Message-ID: <87y24xkris.fsf@gnu.org> References: <87tufmjyai.fsf@gnus.org> <87h7blzmjj.fsf@gnu.org> <87y24xjlme.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35958"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: "Alfred M. Szmidt" , emacs-devel@gnu.org, Lars Ingebrigtsen , rms@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 07 04:45:59 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 1muRQT-00094n-W7 for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Dec 2021 04:45:58 +0100 Original-Received: from localhost ([::1]:42272 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1muRQS-0004qk-F4 for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Dec 2021 22:45:56 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60190) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1muRPR-00049C-RQ for emacs-devel@gnu.org; Mon, 06 Dec 2021 22:44:53 -0500 Original-Received: from [2001:470:142:3::e] (port=53360 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1muRPR-0003yQ-EX; Mon, 06 Dec 2021 22:44:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=FHG27ylUSaZv6pIJUgl/hpFO4um+vLVUPzDlbCWCcW4=; b=r6d5Qmr8clt6YvJ1X3UJ oFWp1f7aGRehRDLg2E0mN09afC2jvCCT0EHCCoKjKkdduBci9fbdg99YB9clVKJKKziwvIfhyUtAq 3fKkfED2C19q7a4prAMDVFEhD85YfrngPOi9vKzY1KjtyOK4M7L7PT+q3QoC9R0zH5mEjTfx9qelb Pme8dZpB4N+nsgEsCjI/+Bk6tHM2E03AFE9aKc8AshODMwQ9qKQrrZPVeBuLUCBVYDOnWitdjYHUB hEqm/eXgwdgUZp1bFUl54w2ihsQehjr3Dojc4uQM/XEa2QkiQwFcWdCPeRYZnDQtgDcUkQ1KDVnSV jj3nRnu2gfBwgQ==; Original-Received: from [141.143.193.70] (port=60754 helo=termi.gnu.org) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1muRPL-0004ul-Gk; Mon, 06 Dec 2021 22:44:47 -0500 In-Reply-To: <87y24xjlme.fsf@yahoo.com> (Po Lu's message of "Tue, 07 Dec 2021 08:37:29 +0800") 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:281195 Archived-At: > "Jose E. Marchesi" writes: > >> gdbm may or may not be what you need in Emacs. >> sqlite is not a replacement for gdbm. >> recutils is not a replacement for sqlite. > >> It seems to me that any discussion in which it is raised the alternative >> of using so disparaged systems such as gdbm, sqlite and recutils for >> some particular purpose, is in serious need of some clarification on why >> a database sytem is needed to begin with and the nature of the data to >> be stored there. > > The idea is that people want a way to store key-value pairs quickly (as > in, faster than a hash table serialized with `print'). Hence the idea > to use (g)dbm. If these are your requirements then I wouldn't recommend you to use recutils, for several reasons. Let me mention just a few. First, recfiles are intended to be edited by hand as well as programmatically. This makes them sort of redundant, not very compact, and also not the fastest format to parse and operate on. Second, recutils supports relational and data integrity features that may not be very useful in your case. If as I suspect you plan to expose a sort of data structure in Elisp to support key-value pairs (like what, persistent a-lists backed by a dbm file?) people using them will undoubtly want to implement their own data integrity logic, or even none. You don't want to use anything that has its own ideas of what a date looks like or how to compare them, for example. This also applies to sqlite and other relational database systems. Third, recutils field keys are restricted to be something similar to a C identifier, like in the record below from the GNU poke TODO file: Summary: unify `break' and `continue' in the same AST node Component: Compiler Kind: ENH Priority: 3 Description: + The `break' and `continue' statements are similar enough to merit + using the same kind of AST node, which would require a discriminant + field (kind = break | continue). + + Likewise, there is some code duplication in the assembler which may be + optimized: pkl_asm_break_label_1 vs. pkl_asm_continue_label_1. Target: 2.0 it follows that if your pair keys can be arbitrary Elisp values then you would be forced to use quite unnatural records like this for an a-list '(("foo" (1 2 3) ("bar" (4 5 6)) (nil (0))): Key: "foo" Value: (1 2 3) Key: "bar" Value: (4 5 6) Key: nil Value: (0) Fourth, you would also have problems with opaque lisp objects that don't have a printed representation, in both keys and values. Fifth, it seems to me that you don't need the notion of a "record" (recutils) nor a relation (sqlite) in a key-value database. If you come with persistent a-lists (or similar) just pluck them into another list, which may be itself be persistent and also backed by dbm. And so on... gdbm seems to provide exactly what you want, using Lisp_Objects as keys and values. I would just rejoice and use it :)