From b197c2aebadf84a41eb32697862470b825ac3ad4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Padez?= Date: Mon, 10 Aug 2026 13:11:01 +0000 Subject: [PATCH] =?UTF-8?q?app=20store:=20settle=20the=20lifecycle=20?= =?UTF-8?q?=E2=80=94=20disable=20stops=20the=20container,=20uninstall=20ke?= =?UTF-8?q?eps=20the=20schema?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Disable now stops the container as well as the sidecar. There is no reason to leave Immich holding memory while Photos is switched off. For mode 'existing' there is no container of ours, so disable is only the sidecar. Uninstall stops both, removes the containers, and deletes the install row. It does NOT drop the sidecar's tables — pushing back on "maybe db schema too" for the same reason volumes are kept, because it is the same category. Music favourites, the Jellyfin server registry, photos configuration and saved connections are real data, and someone uninstalling Photos is saying "stop running this", not "forget which albums I favourited". Keeping them also makes reinstall a RESTORE: uninstall in June, reinstall in August, and the configuration is still there. Dropping the schema would hand back a blank service that looks subtly broken to someone who remembers setting it up. An unused table costs a row in information_schema and nothing else. Also removes a line left stale by the previous commit, which still said the user chooses disposal at uninstall time. There is no such choice any more, and a doc that describes an option the code does not have is how the option comes back. Co-Authored-By: Claude Opus 5 --- docs/sidecar-app-store.md | 30 ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/docs/sidecar-app-store.md b/docs/sidecar-app-store.md index bb45a288..dbbff301 100644 --- a/docs/sidecar-app-store.md +++ b/docs/sidecar-app-store.md @@ -140,14 +140,32 @@ Two independent flags, because they answer different questions: - **`installed`** — the thing exists: container provisioned, config written, schema applied. - **`enabled`** — the process should be running. -That yields the three outcomes asked for: +| Action | Sidecar process | Container | Data & schema | +| ------------- | --------------- | ------------------------------ | ------------- | +| **Disable** | stopped | stopped | untouched | +| **Enable** | started | started | untouched | +| **Uninstall** | stopped | `docker compose down`, removed | untouched | -| Action | Effect | -| ------------- | -------------------------------------------------------------------------------------------------------------------------------- | -| **Disable** | Stop the sidecar. Container, config, schema and data all stay. Re-enable is instant. | -| **Uninstall** | Stop the sidecar, `docker compose down` — containers and networks removed. **The service directory and everything in it stays.** | +Disable stops the container too — there is no reason to leave Immich holding memory while Photos is +switched off. For `mode: 'existing'` there is no container of ours, so disable is only the sidecar. -The middle one is the in-between; the user chooses disposal at uninstall time rather than us guessing. +Uninstall additionally deletes the `sidecar_installs` row. It does **not** drop the sidecar's tables. + +**Nothing above deletes data, and there is no option that does.** + +### Why the schema survives uninstall too + +Dropping a sidecar's tables is deleting data. Not media, but real: music favourites, the Jellyfin server +registry, photos configuration, saved connections. That is the same category as volumes and gets the +same answer. + +It also buys something. **Reinstall becomes restore** — uninstall Photos in June, reinstall in August, +and the configuration and favourites are still there. Drop the schema and reinstalling hands back a +blank service that looks subtly broken to someone who remembers setting it up. + +Keeping them costs nothing: an unused table is a row in `information_schema`. No queries, no memory, no +maintenance. Dropping them joins volume deletion in the later, deliberate cleanup feature, where the +user sees what they are removing. **Install must be idempotent and resumable.** Provision → health → config → schema → start is five steps and any of them can fail. The failure mode to design against is a half-installed service that neither