Adding initial data insertion into setup script#2293
Merged
Conversation
…compare to the sql (to be dropped later when we have the next migration)
…ry key which can get larger
jessevz
approved these changes
Jul 1, 2026
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
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.
With the way migrations work with sqlx we will have trouble in the future to adjust existing sql data to changes (e.g. new hashcat version, new agent binary versions).
Due to this, we move all the initial insertion data outside of the initial sql files and insert them on the first setup steps (where also the admin user is created) on the very first start. This allows to change values later without having to create a complete new migrations generation just for changing an initial value like a version number.
What still has to be solved, is how agent binaries are upgraded for existing setups. For this there are two options how we could achieve this:
Currently we have the initial data both in the initial sql of the current generation and also check to insert it on the setup. This is not problem, as it checks if the given IDs already exist. At a later point on the next migrations generation, we can throw out the initial data from the sql scripts.