From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.devel Subject: Re: persistent data feature, or sqlite3 feature? Date: Mon, 14 Feb 2022 17:07:29 +0300 Message-ID: References: <87o85tcwm0.fsf@ericabrahamsen.net> <874k7ljwkr.fsf@gnus.org> <87fsr5cuzq.fsf@ericabrahamsen.net> <878rwx8mdn.fsf@gnu.org> <87r1aphuei.fsf@gnus.org> <837dcex6ub.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9347"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.2.0 (2022-02-12) Cc: eric@ericabrahamsen.net, cesar.mena@gmail.com, emacs-devel@gnu.org, Pip Cet , larsi@gnus.org, eliz@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Feb 14 15:47:00 2022 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 1nJcd1-0002CN-As for ged-emacs-devel@m.gmane-mx.org; Mon, 14 Feb 2022 15:46:59 +0100 Original-Received: from localhost ([::1]:56958 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nJccy-0001e7-Td for ged-emacs-devel@m.gmane-mx.org; Mon, 14 Feb 2022 09:46:57 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43828) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nJc31-0006WY-CI for emacs-devel@gnu.org; Mon, 14 Feb 2022 09:09:47 -0500 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:34425) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nJc2z-0004Ey-HG; Mon, 14 Feb 2022 09:09:47 -0500 Original-Received: from localhost ([::ffff:41.75.189.127]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000055D52.00000000620A629F.000077FB; Mon, 14 Feb 2022 07:09:34 -0700 Mail-Followup-To: Richard Stallman , Pip Cet , eric@ericabrahamsen.net, cesar.mena@gmail.com, eliz@gnu.org, larsi@gnus.org, emacs-devel@gnu.org Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham 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:286272 Archived-At: * Richard Stallman [2021-12-10 07:54]: > A general-purpose database package such as sqlite3 surely does not > come with a built-in representation for storing Lisp objects in > general. Emacs would need to have a way to encode them as byte > sequences, and store those byte sequences in the database. > (This encoding might be `prin1' or it might be something else.) Not that it exists that I know, and not that it would be hard to make specific Emacs Lisp type for SQLite In my personal usage I am converting Emacs Lisp by using prin1-to-string into the text type of a storage in database and getting it back from there by using eval. > It follows that sqlite3 databases containing persistent Lisp data > stored by Emacs will not in general be naturally interoperable with > sqlite3 databases made by other programs. It does not follow. SQLite databases are manageable by other programs. That data has been written as Lisp is not relevant. Also text files with Emacs Lisp are not easily run by other programs. > Other programs won't know about this encoding. If the other program > is meant to be a general tool, such as a database explorer, it could > I suppose operate on Emacs database files, but anything that really > wants to understand its data won't interoperate with Emacs. Other programs don't understand Emacs Lisp, true. But other programs for database management can easily operate on SQLite files created by Emacs. Interoperability is thus built-in. > It follows that there is no particular benefit from using a > general-purpose database system such as sqlite3 _for the purpose of > holding persistent Lisp data_. I am doing it all the time, since years already. It is clear that you do not see the benefit, this is because lack of experience with databases. Your personal opinion cannot however dispute the fact that storing information in the databases, especially into relational databases brings many benefits to computer users, including to programmers. Imagine Emacs profiles, instead of text files, user could press "N" for new profile or "C" to copy a profile. Profile could contain packages A, B, C, D, while other profile could contain only C, D packages; including one profile could have quite different configuration made for the work in other time zone, different city and different language, with different input systems and different spell checking; other profile could be quite different. Simple click could switch between profiles with the certainty and reliability of data stored. File system is a database. Though maybe not as sophisticated as relational databases. For example, we would have such a trouble finding all files on the file system stored on Mon 14 Feb 2022 05:04:15 PM EAT and it would take quite long time. Using more sophisticated databases to store data can only be helpful. Databases have indexes, and finding objects (files) stored after Mon 14 Feb 2022 05:04:42 PM EAT would be a breeze. Numerous intersections queries are available in relational databases. > 1. Persistent objects. > > 2. Access to arbitrary sqlite3 databases. > > and that makes it incoherent. > > We could implement either feature. We could implement both. > But one of them should not control the design of the other! I don't think those are incoherent. I think that (2) access to arbitrary sqlite3 databases provides (1) persistent objects by usage of Emacs Lisp or Emacs C programming (even better); and C programming should use arbitrary sqlite3 database with the difference that it would take care of conformity of sexps stored. By implementing (2) direct Emacs access to arbitraty sqlite3 database (which already exists through Emacs packages) one achieves (1) to create persistent objects or anything else one wish and wants. Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/