fix(sites): stop treating SQLite as a service a project installs - #1404
Merged
Conversation
A site page showed sqlite as a service that was not installed, with an offer to install it. There is nothing to install: sqlite has no preset, is not among the default preset names, and never runs in a container. It is a file the application opens. It got there because the database step offered it to every framework, hardcoded at the top of the list in Go, and the choice was then written into .lerd.yaml as a services entry alongside the services lerd really does run. Everything downstream treated it as one, down to the card whose vocabulary of installed, running and stopped applies to none of it. Which databases a framework can use is the definition's to declare, like everything else about how it is wired, so the option now comes from a declared sqlite service and a framework declaring none does not offer it. A project lerd recognises no framework for keeps the option, since nothing has declared otherwise and a file database is a reasonable answer for it. Choosing it records nothing. The project's own configuration already says it is on SQLite, which is what lerd reads to answer which database a site uses, so recording it a second time only creates an entry to explain away. Projects carrying the entry from an older lerd are unchanged on disk and it is ignored where it is found, so the phantom disappears without rewriting anyone's file.
The wizard recombines the database pick with the other selections into the services list saved to .lerd.yaml, and appended the pick unconditionally, so choosing SQLite still recorded it. That is the entry the rest of this change exists to stop producing, reached by the path most projects actually take. The recombination moves into a function of its own so the rule is stated once and can be tested, rather than sitting inline in a wizard that needs a terminal to run.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A site page showed sqlite as a service that was not installed, with an offer to install it. There is nothing to install: sqlite has no preset, is not among the default preset names, and never runs in a container. It is a file the application opens.
It got there because the database step offered it to every framework, hardcoded at the top of the list in Go, and the choice was then written into .lerd.yaml as a services entry alongside the services lerd really does run. Everything downstream treated it as one, down to the card whose vocabulary of installed, running and stopped applies to none of it.
Which databases a framework can use is the definition's to declare, like everything else about how it is wired, so the option now comes from a declared sqlite service and a framework declaring none does not offer it. A project lerd recognises no framework for keeps the option, since nothing has declared otherwise and a file database is a reasonable answer for it. No published definition declares one yet, so this takes the option away until they do, which is the point: it was being offered to frameworks that cannot use it.
Choosing it records nothing. The project's own configuration already says it is on SQLite, which is what lerd reads to answer which database a site uses, so recording it a second time only creates an entry to explain away.
Projects carrying the entry from an older lerd are unchanged on disk and it is ignored where it is found, so the phantom disappears without rewriting anyone's file. Verified against a real site whose .lerd.yaml still lists sqlite: its services read mailpit and postgres, with no sqlite among them, and the other sites are untouched.
Closes #1398