officerdev/platform
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

app store: settle the lifecycle — disable stops the container, uninstall keeps the schema

Browse Source 
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 <noreply@anthropic.com>
This commit is contained in:
pastilhas
2026-08-10 13:44:30 +00:00
co-authored by Claude Opus 5
parent 936b96a36e
commit b197c2aeba
1 changed files with 24 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/sidecar-app-store.md
+24 -6
View File
@@ -140,14 +140,32 @@ Two independent flags, because they answer different questions:
- **`installed`** — the thing exists: container provisioned, config written, schema applied. - **`installed`** — the thing exists: container provisioned, config written, schema applied.
- **`enabled`** — the process should be running. - **`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 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.
| **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.** |
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 **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 and any of them can fail. The failure mode to design against is a half-installed service that neither