From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Landscheidt Newsgroups: gmane.emacs.help Subject: Re: Interacting with PostgreSQL Date: Mon, 30 Nov 2020 03:12:44 +0000 Organization: http://www.tim-landscheidt.de/ Message-ID: <87y2ij8rmb.fsf@passepartout.tim-landscheidt.de> References: <87r1oms1z3.fsf@passepartout.tim-landscheidt.de> <87sg8yuz33.fsf@passepartout.tim-landscheidt.de> <87blflvi1j.fsf@passepartout.tim-landscheidt.de> <87sg8xtldp.fsf@passepartout.tim-landscheidt.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21480"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:FBNGt+53ONuOVI91TVACzmh16+U= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 30 04:18:12 2020 Return-path: Envelope-to: geh-help-gnu-emacs@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 1kjZhb-0005UE-N9 for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 30 Nov 2020 04:18:11 +0100 Original-Received: from localhost ([::1]:57012 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjZha-0001ao-Pq for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 29 Nov 2020 22:18:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41452) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjZcW-00077I-Nk for help-gnu-emacs@gnu.org; Sun, 29 Nov 2020 22:12:58 -0500 Original-Received: from static.214.254.202.116.clients.your-server.de ([116.202.254.214]:50508 helo=ciao.gmane.io) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjZcU-0000Xa-FD for help-gnu-emacs@gnu.org; Sun, 29 Nov 2020 22:12:56 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1kjZcP-000ACN-9F for help-gnu-emacs@gnu.org; Mon, 30 Nov 2020 04:12:49 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:125765 Archived-At: Jean Louis wrote: >> >> The problem is that you do not need to consciously use auto- >> >> commit mode, but that psql automatically reverts to it when >> >> you rollback or commit a transaction: >> >> | tim=> BEGIN WORK; >> >> | BEGIN >> >> | tim=> INSERT INTO t (ID) VALUES (1); >> >> | INSERT 0 1 >> >> | tim=> ROLLBACK WORK; >> >> | ROLLBACK >> >> | tim=> INSERT INTO t (ID) VALUES (1); >> >> | INSERT 0 1 >> >> | tim=> -- The row has been committed. >> > I understand. I always used it manually and will rather continue. Just >> > observing how you do it. >> Eh, that /is/ the behaviour using it manually, either on the >> command line or via sql-postgres. > I understand what you mean. Without BEGIN I am in autocommit > mode. That is standard. But why is it problem for you? Because if I make a mistake in auto-commit mode, potentially all data can be changed or lost. Therefore I want to use a transaction wherever possible so that I can verify the ef- fects of a query before committing it. > […] >> There are org-mode, many markdown variants, plain HTML, and >> apparently even a dedicated GNU project called Hyperbole >> (https://www.gnu.org/software/hyperbole/). > Definitely yes. But those you mentioned are related only by > having hyperlink features. Org mode is outline mode, markdown is not > quite outline neither hierarchical, it is pre-processor for HTML. GNU > Hyperbole I am using daily and started using it back in time, maybe 2 > decades with pauses and never fully used all of the options it > has. Maybe you mean Koutliner in GNU Hyperbole as that is outline > somewhat similar to Org but better structured. > Emacs HyperScope is dynamic knowledge repository that augments > knowledge, relates it together and serves as dynamic knowledge > repository that follows the technology template project for open > hyperdocument systems by Doug Engelbart, definitely similar in its > nature to first Javascript based HyperScope. This one is for Emacs. > About Dynamic Knowledge Repositories (DKR) > https://www.dougengelbart.org/content/view/190/163/ > TECHNOLOGY TEMPLATE PROJECT OHS Framework > https://www.dougengelbart.org/content/view/110/460/ I know. So why use that and not Org mode? >> There are a my- riad of version control systems, with Git at the >> forefront. Most of them are natively supported by Emacs, right out >> of the box. > That is right. And I need to think about such. For example I would > need to check in, check out, and I do that for the files. > When editing database entries, those are not files on file > system. Data comes from the database. That data is itself stored in > some files that PostgreSQL database manages is irrelevant as user has > no access to source files normally, neither is allowed to do some > versioning with such. Interaction goes over TCP or sockets and not > from file access. In that sense when I am editing for example Org > based data it is not file from file system but Org mode formatted data > then there is currently none known versioning system that I know that > is generic for databases. > This can be easily helped with simple procedure that function that is > about to edit the data simply fetch the edited data and stores it in > the version control table before any editing. Version control table > remembers the table, column ID, column, type and value. Right now I am > storing those as text, but not numbers as it need some type casting to > text that I can implement later. Major problem is with larger text > that requires sometimes longer editing. > Because such editing is without files I would like to know if I could > temporarily assign a disconnected file to buffer so that file get > saved from buffer, but when I finish recursive editing that > buffer-string gets returned to my function that stores it into > database. That is yet unsolved problem and could be solution to safety > of data being edited longer time. > Two safety problems are with PostgreSQL data entry editing, one is to > save the previouse entries or historical and that I have solved in > very simple manner. Other problem is to solve the currently edited > text that is nowhere saved. For that reason I wish to find way to > automatically save the buffers somewhere but not that buffer is > connected to the file being saved. > Does anybody have pointers how to do that? > […] I have absolutely no idea /why/ someone would store Org mode data in a database and then wonder how to implement a form of version control for it. Emacs is very good at editing files, Git is very good at versioning them, it has plenty of commands to create branches and worktrees and everything else one of the millions of projects using it has ever need- ed, and Emacs Lisp is more than versatile enough to code every imaginable workflow. Some of the brightest minds have worked on them extensively, either from a formally educated perspective or with the ex- perience of blood and tears. These giants are inviting everybody to stand on their shoulders, and neither would I ignore them nor would I recommend others to do so. Tim