GNU bug report logs - #76025
[PATCH 1/1] * lisp/progmodes/sql.el: login without prompting

Previous Next

Full log

View this message in rfc822 format

From: Michael Mauger <mmauger <at> protonmail.com>
To: Phil Estival <pe <at> 7d.nz>
Cc: 76025 <at> debbugs.gnu.org, Ihor Radchenko <yantar92 <at> posteo.net>, Org Mode List <emacs-orgmode <at> gnu.org>
Subject: bug#76025: [PATCH] ob-sql: session
Date: Wed, 18 Jun 2025 01:15:11 +0000

On Monday, June 16th, 2025 at 12:19 PM, Phil Estival <pe <at> 7d.nz> wrote:

> * [2025-06-15 20:59 +0000] Michael Mauger mmauger <at> protonmail.com:
> 
> > On Sunday, June 15th, 2025 at 3:16 PM, Phil Estival pe <at> 7d.nz wrote:
> > 
> > > I also took good note of Michael's remarks.
> > > The attached series of patches will work
> > > without any modification to sql.el. I'll introduce later a local
> > > `sql-connection' bound to the session name. In the absence of it,
> > > sessions will work, but will ask to confirm provided connection
> > > parameter upon establishing connection.
> > 
> > Wouldn't the SQLi buffer created by sql-connect be the session?
> 
> 
> Yes, right. The session is an identifier name, the buffer's name is
> build on that name but the connection's name can be shared among
> sessions.
> 

I'd suggest remembering the buffer itself rather than the buffer name. Also, like `sql-product-interactive', you can control a portion of the buffer name in the `sql-connect' call. But again, it would be safer to use the buffer itself to memoize the session. Your org session name would translate to the buffer rather than the potentially changed buffer name.

> > At least in sql.el, when it uses either sql-connect or
> > sql-product-interactive, all the buffers are scanned to for the
> > desired connection settings and switch to the matching buffer rather
> > than creating a new buffer.
> 
> 
> Aren't they opened in parallel, one connection each, with the same
> connection parameters ?
> 
> `org-babel-sql-session-connect' uses` sql-product-interactive' with a
> buffer name as argument. Different sessions are run in different sql
> interactive buffers, yet they have the same connection settings.
> 

The name will be used as part of the match, so using different names will become different buffers. But I need to look at that logic a bit to insure it has consistent behavior.

> > I am trying to cleanup sql.el 2.x before I do a more significant
> > rewrite for sql.el 3.0. The update will include sql-add-connection
> > which cleanly adds an entry to sql-connection-alist and the ability to
> > call sql-connect with with the connection settings themselves rather
> > than the connection name. Hopefully those will simplify the
> > integrations that you need.
> 
> 
> Fine.
> 
> > And please let me know if you are not getting the behavior you want,
> > or if you are working around something that I ought to look at....
> 
> 
> * [2025-05-19 01:36 +0000] Michael Mauger mmauger <at> protonmail.com:
> 
> > For sqlite, I've added support for an in-memory database using the
> > name ":memory:" in my local repo. Obviously an empty name indicates a
> > temporary database which may be in-memory, or if larger, in temporary
> > disk space. I'll take a look at adding support for temporary databases
> > but I'm not a huge fan of an empty database name option. Maybe support
> > ":tempdb:" (or similar)?
> 
> 
> The message sqlite3 displays on the welcoming message is:
> "Connected to a transient in-memory database.", so perhaps
> the proper word is ":in-memory:" ?
> 
> While the empty string as database name should IMHO be avoided, the nil
> parameter must still be allowed:
> 
> "If no database name is supplied, the ATTACH sql command can be used to
> attach to existing or create new database files. ATTACH can also be
> used to attach to multiple databases within the same interactive
> session. This is useful for migrating data between databases, possibly
> changing the schema along the way."
> 

The nil database should work already, but really means ":memory:" which is sqlite's default in-memory database, in which ATTACH commands can still be used. 

> Cheers,
> --
> Phil Estival

I have been dealing with sick family for the past month and will be unavailable for at least the next week. I expect to have some coherent changes to sql.el by early July; I apologize for the delay but its been a chaotic 6 weeks but appears to finally be settling down... 

-- 
MICHAEL <at> MAUGER.COM // FSF and SFConservancy // GNU Emacs sql.el maintainer

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.