I basically agree with Jared, at least as far as the broken UX of sql-mode goes. If you say it’s broken, it’s broken.

What I don’t understand is this: Here we have a coder, willing to investigate solutions to his problems. Reads documentation. Presumably Googles. Finds something that appears to be what he wants. Tries it, and gets one error message. Gives up and writes his own.

I like to think I’m well acquainted with human laziness, but this is a species I just don’t understand. But that’s somewhat off point now.

So. We can agree that:

• The UX of sql-mode is bad.
• Nobody has clearly explained how to use it.

Given this situation, I think it’s insane to say that the correct solution is to document how to work around the bad UX. So, I’ve put my money where my mouth is and patched sql-mode to improve it’s behavior. So with this patch, SQL-mode:

• Has a sql-change-buffer function, which can set or change the sql-interactive buffer the sql-mode buffer will send commands to. The command has a default keybinding, and auto-completes buffer names. It only completes names of live interactive SQL buffers.
• Has a visual indicator (in the mode-line) of which SQLi buffer the current SQL buffer is tied to.
• If you run one of the sql-send-* commands, and sql-buffer isn’t pointing to a live SQLi buffer, you get an error which points you to sql-change-buffer.

Here’s the patch: sql-change-buffer, against Emacs’ CVS HEAD. It’s still a bit rough around the edges. In particular, I’m not thrilled with how sql-buffer is indicated in the mode-line. Contributions are welcomed.

Now, I agree with this to a point. Documentation for third-party Emacs packages can be scattered and hard to come by. The EmacsWiki search is terrible, and shouldn’t be relied on. But in this specific case, I just don’t buy it.

SQL-mode is built in to Emacs, and Emacs is called self-documenting for a reason. All the packages it ships with have easily accessible documentation; even a cursory search of sql-mode should have shown that the feature he wanted already existed. For the record: In a SQL buffer, accessing the major mode help (C-h m) shows this in the very first sentence of the description:

You can send SQL statements to the SQLi buffer using C-c C-r.

Which just goes to show that it doesn’t matter how good the documentation is when people don’t bother to read it.

Now, this isn’t to say that it’s pointless to reinvent the wheel. You’ve got to learn to make wheels somehow, right? But my problems with database-mode run a little deeper than this.

On a personal level, I find it hard to trust the code of someone who can’t RTFM. If they didn’t bother figuring out that their feature already exists, what else have they overlooked? I admit that this is pedantic and unfair in some cases. But I feel the point has some validity: If you can’t be trusted with the small stuff, why should I trust you with the big stuff?

The other point I want to make is that forks like this hurt the community. The active Emacs developer community is pretty small compared to some other projects, so the available developer effort is small and precious. Spending it reimplementing features already available in vanilla Emacs seems like a waste to me.

Everyone has been guilty of this at some point, myself included. We owe it to ourselves and the community to do better.

Better Buffer Naming

I found this code somwhere a while back, and threw in some enhancements:

1. If sql-name is set, that is used in the buffer name, e.g. “*SQL sql-name*”
2. Otherwise, the name will include the hostname of sql-server and sql-database. If sql-server is an IP address, it’s used; if it’s a DNS name, the hostname part is used. e.g. “*SQL: dbhost/dbname*” or “*SQL 192.168.0.1/dbname”

(defun sql-make-smart-buffer-name ()
  "Return a string that can be used to rename a SQLi buffer.

This is used to set `sql-alternate-buffer-name' within
`sql-interactive-mode'."
  (or (and (boundp 'sql-name) sql-name)
      (concat (if (not(string= "" sql-server))
                  (concat
                   (or (and (string-match "[0-9.]+" sql-server) sql-server)
                       (car (split-string sql-server "\\.")))
                   "/"))
              sql-database)))

(add-hook 'sql-interactive-mode-hook
          (lambda ()
            (setq sql-alternate-buffer-name (sql-make-smart-buffer-name))
            (sql-rename-buffer)))

Support for TCP Ports

At Digg, we have a lot of databases. As you may have read, we have four main pools of databases. Each of these has one write master and several slaves. We have this setup duplicated in many places for production, development, QA, and so on. While the less-stable environments don’t require the full setup, we try to balance consistency with resource usage. What we’ve settled on is one physical host running four different MySQL instance, one for each pool, each listening on a different port. Unfortunately, sql-mode has no support for this. You can set the sql-*-options variables, but this is cumbersome when you need to quickly connect to servers on different ports.

This simple advice will add sql-port into sql-mysql-options, if it’s set.

(defadvice sql-connect-mysql (around sql-mysql-port activate)
  "Add support for connecting to MySQL on other ports"
  (let ((sql-mysql-options (or (and (boundp 'sql-port) sql-port (cons (concat "-P " (or (and (numberp sql-port) (number-to-string sql-port)) sql-port)) sql-mysql-options)) sql-mysql-options)))
    ad-do-it))

Currently, this ony works for MySQL. It should be trivial to extend the support for other databases.

This doesn’t get read interactively like the other options, so you’ll have to create a new function with a let binding to connect. This isn’t such a bad thing when you throw in the next enhancement.

Support for Preset Connections

It’s not much fun to enter your connection information every time you want to connect. I had some functions which used let expressions to set the correct defaults for connections, but this was suboptimal, since you had to hit RET a bunch of times before the connection would start. This is fixed with preset connections. You define sql-connection-alist with a connection name and a list of sql variables to bind. Then you may call sql-connect-preset with the connection name, and you get your connection immediately.

Note that you can specify sql-port in the connection definition. Also, sql-name is defined to the name of the connection, so you can set the buffer name there, as well.

At some point in the future, it would be a good idea to make an interactive version of sql-connect-preset, which prompts you for one of the defined connections. For now, though, you need to define a function.

Example code:

(setq sql-connection-alist
      '((pool-a
         (sql-product 'mysql)
         (sql-server "1.2.3.4")
         (sql-user "me")
         (sql-password "mypassword")
         (sql-database "thedb")
         (sql-port 3306))
        (pool-b
         (sql-product 'mysql)
         (sql-server "1.2.3.4")
         (sql-user "me")
         (sql-password "mypassword")
         (sql-database "thedb")
         (sql-port 3307))))

(defun sql-connect-preset (name)
  "Connect to a predefined SQL connection listed in `sql-connection-alist'"
  (eval `(let ,(cdr (assoc name sql-connection-alist))
    (flet ((sql-get-login (&rest what)))
      (sql-product-interactive sql-product)))))

(defun sql-pool-a ()
  (interactive)
  (sql-connect-preset 'pool-a))

Now, you can just run sql-pool-a and get connected right away. Because the buffers have good names, you can easily fire up many connections.