Grove 1.11.0: finding the one you were working on

Somewhere in the last year, Grove's Sites list stopped being a list and became a scroll.

I don't think anyone planned that. You add a project because you need it for an afternoon. Then a client's staging copy. Then a worktree for a branch you were reviewing. Then the old version of something you keep for reference. One day you count, and it's 140. Finding the one you were just working on means scrolling past a hundred you weren't.

1.11.0 is about that, and about a second thing I care about more than I expected: making sure the database you depend on moves forward without you having to think about it. Let me take them in turn.

Part one: ⌘K

Why: the list is sorted by the wrong thing

A long list is fine if it's sorted by what you want. The Sites list is sorted by name, because name is the only thing that's always true of a site. But when you open Grove, you almost never want "the site whose name comes first." You want the one I was working on twenty minutes ago.

So the question is how Grove can know that.

How: three signals, and it tells you which

Press ⌘K anywhere in the app. With nothing typed, you get the ten projects you worked on most recently. A project counts from the newest of three signals, and the palette tells you which one won:

shop.test          git 20m ago
billing.test       request 3m ago
docs.test          opened just now

The three signals are:

Activity in its git repo: the modification times of the index, HEAD and its log. For a worktree it follows the .git file to the real repository.
The last request Grove served it. If you're hitting billing.test in the browser, you're working on it, whether or not you've committed anything.
The last time you opened it from Grove.

Saying which signal it was is a small thing that makes the list trustworthy. "Why is this at the top?" has an answer right there, in the row.

There's one detail I love. The git signal leaves out FETCH_HEAD. A background git fetch touches that file, and a background fetch isn't you working. Without that, a tool that fetches every few minutes would shove whatever it's fetching to the top of your recent list all day. The changelog's phrasing is exactly right: a background fetch is not you working.

Typing

Start typing and the palette fuzzy-searches every site, by hostname first and then by path. The example from the testing is a good one: in a scratch Grove with 144 sites, typing abn finds abonnementsoversikt.test first. You don't need the whole name, just enough of it to be unique.

The keys are what you'd hope for:

↑ ↓ to choose.
↵ focuses the Sites list on that one project, with a chip you can click to clear it.
⌘↵ opens it straight in your browser.

And the palette keeps what you typed through Grove's four-second background refresh. That sounds like nothing until you've used a palette that eats your half-typed word when the list updates under you.

A filter, for when you'd rather look

Sometimes you don't want a palette, you want the list, just shorter. Above the Sites list there's now a filter. Focus it with / or ⌘F. Every word must appear in the site's name, path, driver or PHP version, and it shows how many matched, as "N of M".

So shop 8.3 narrows the list to the sites with "shop" somewhere in them and PHP 8.3, and the count tells you how many of your 140 that left. I find the "N of M" more useful than I expected: it tells you immediately whether your filter was too tight.

Was it tested on anything real?

It was. The changelog is specific about it: driven by keyboard in Chrome, against 144 sites and the git repos of a scratch Grove. The recent list ranked two sites with requests, a worktree, and three repos worked on between 23 minutes and six days ago, in the right order. Nobody had to take the ordering on faith.

Part two: ElyraSQL moves on its own

Why this mattered this week

ElyraSQL 1.12.0 came out with two security fixes. Both are ways around column grants:

A user granted some columns of a table could read the others, either through UNION:
```
SELECT secret_column FROM t UNION SELECT 'x'
```
or by copying them out with INSERT ... SELECT.
A replica didn't enforce grants or schema changes made on its primary after the replica had started.

I want to be careful about scope here, because it's easy to scare people. Grove runs ElyraSQL without accounts, on loopback, so Grove itself was not exposed. Column grants only matter if there are accounts to restrict. But a project that created accounts in its ElyraSQL was. If your app does CREATE USER and relies on grants to keep one user out of another's columns, that's a real hole, and the fix is a new version.

Grove 1.11.0 pins ElyraSQL to 1.12.0, and, this is the point, moves an existing install there by itself.

How it happens

When the daemon starts, it sees the 1.11.x build beside your data, fetches 1.12.0 in the background, and starts it if it was running before. Your database file isn't touched. The old build stays on disk until you decide to remove it:

rm -r ~/…/services/elyrasql/elyrasql-1.11.*

There's nothing to run and nothing to click. The changelog's own line for it is "Nothing else needs doing. The app updates itself as before."

The bug I'd have been embarrassed by

Here's the part I find most instructive.

Grove 1.10.1 had already taught the daemon to upgrade services by itself. But it only did so when the pin moved to a patch release of what you had installed. Fine for 1.11.3 → 1.11.4. But 1.11.4 → 1.12.0 is a minor step, and the changelog states the consequence without softening it: it would have logged the command to run and left ElyraSQL stopped.

In other words: for exactly the users who most needed the security fix, the old rule would have quietly turned off their database. Because it "would have", nobody was hit. Someone checked the next pin against the rule before it shipped. I'd like to say that's always how it goes, and it isn't.

So the rule is now per server:

Service Moves by itself Why ElyraSQL within a major version it keeps a database in one file that any release of that major opens MySQL, PostgreSQL patch releases only their data directories don't always carry across a minor Redis patch releases only it's built from source all of them never backwards

The asymmetry is the sensible part. A single file that every release of the major can open is safe to move. A MySQL or PostgreSQL data directory is not, so Grove leaves those minor steps to you.

Checking the claim that matters

"The database file is not touched" is the kind of sentence that's easy to write and hard to be sure of, so the verification is worth quoting in full. With the released 1.10.1, a scratch home installed ElyraSQL 1.11.4 and wrote three rows. The new daemon then fetched 1.12.0 and started it on the same .edb: the same inode. It read the three rows back unchanged, and took a fourth.

Same inode is the detail that does the work. It means not "a copy that looks the same" but the same file on disk, with the new server reading and extending it.

Two things a project might notice

1.12.0 behaves more like MySQL in two ways you can see. The changelog flags both, and so will I:

1. AVG over an integer column now returns DECIMAL, not DOUBLE.

SELECT AVG(quantity) FROM orders;   -- a DECIMAL now

If your code decodes that strictly as a float (sqlx f64 is the example the changelog gives), it has to accept a decimal. It's a correctness improvement, and it's the same thing MySQL does, but a strict decoder will notice.

2. An account made with CREATE USER now starts with no privileges. As in MySQL, it no longer reads every table by default:

CREATE USER app IDENTIFIED BY '…';
GRANT SELECT ON shop.* TO app;     -- now required

Grant it what it needs. Accounts created before the update keep the privileges they had, and Grove's own access runs without accounts on loopback, so it's unaffected.

And a pleasant thing comes along with them: ElyraSQL 1.12.0 is much faster. Point queries use less than half the CPU, and LOAD DATA is 2.4× quicker.

Housekeeping

The release also brings the app's dependencies up to date: Tauri 2.11.6, the updater plugin 2.12 (Rust and JavaScript sides together), Svelte 5.57.1 and Vite 8.3.1. The release workflow moves to actions/upload-artifact v7 for its dry runs, and a dry run on the merged main built, signed and notarized both platforms with it. A small detail, but it's the reason I trust the DMG.

So, should you update?

Yes, and there's nothing to arrange. The app updates itself as before. On first start:

The daemon notices the 1.11.x ElyraSQL beside your data.
It fetches 1.12.0 in the background and starts it if it was running.
Your database file stays exactly where it was.

If you never create accounts in ElyraSQL, the security fix doesn't touch you, but you get the speed. If you do, it was worth having yesterday.

Then press ⌘K. Type three letters of something you worked on last week. And notice how long it takes you to get there.