summaryrefslogtreecommitdiff
path: root/model/database.go
AgeCommit message (Collapse)Author
2024-05-09model: Require same version for executable and DBxengineering
Currently only an empty database and an existing database with the same version are supported. Support for migrations based on semantic versioning will be added in future versions of Ceres.
2024-05-09model: Migrate only in empty databasesxengineering
2024-05-09model: Initial database version injectionxengineering
If the database was empty on startup a metadata table with a key and value row is created. In addition the Ceres executable version is inserted as value under the key 'version'. This allows to detect on not-empty databases which Ceres version was used before which is the starting point to implement migrations.
2024-05-09model: Detect if database is emptyxengineering
An empty database requires to add the metadata table with the version entry to make migrations possible. Thus this detection will be required.
2024-05-09model: Wrap migration completely in transactionxengineering
This makes it more clear that the full migration will be rolled back on errors.
2024-05-09model: Use defer for tx.Rollback()xengineering
A committed transaction cannot be rolled back. Using defer to roll back guarantees that the transaction is always rolled back if not the commit in the last line of model.Transaction was excuted. [1]: https://go.dev/doc/database/execute-transactions
2024-05-09Restructure database-related functionsxengineering
2024-05-08Introduce model.Transaction()xengineering
It is a very common pattern that some function needs to access the database and wants to wrap all the actions into one transaction. The advantage of a transaction is that it is ACID: - atomic - consistent - isolated - durable In Go it is required to request a new transaction, execute functionality on it and handle rollback or commit of this transaction based on the success of the operation. All this and the error handling can be written down in the model.Transaction() function exactly once. The full signature of it is: func Transaction(f func(*sql.Tx) error) error It requires a function or closure passed as argument which takes the transaction (*sql.Tx) and returns an error which might be nil. This is very generic. It is applied to: - injecting test data - database migrations - data read requests - data write requests
2024-05-07model: Init database with database pathxengineering
2024-05-01Use default storage path instead of temp dirxengineering
2024-04-06model: Always pass *sql.Tx to CRUD methodsxengineering
When nesting objects like steps into other objects like recipes it is required to pass a *sql.Tx value to the CRUD methods of the inner object to be able to roll back the whole transaction. The top level object used to be responsible for the creation of this *sql.Tx inside its CRUD methods. This is now moved to the caller of the CRUD methods (here the HTTP handler function). The advantage is that all CRUD methods now accept a *sql.Tx as only argument which makes those methods more consistent.
2024-03-24model: Add recipe stepsxengineering
This provides the infrastructure to create views and HTTP handlers to provide recipe steps.
2024-03-24model: Crash on failed test recipe injectionxengineering
This error used to be silent. Since it is just about test recipes and thus a debugging environment it is best to directly give up and log the error.
2024-03-04model: Create test data with Go instead of SQLxengineering
This allows to formulate the test data with an object-based model which is easier than writing it down in a relational model.
2023-12-27model: Inject test data into databasexengineering
This is useful for debugging and testing.
2023-12-27model: Add initial SQL migrationxengineering
This provides the basic table structure to the database.
2023-12-27model: Implement database connectionxengineering
The already implemented storage folder should contain a sqlite database to store most parts of the Ceres user data.