| Age | Commit message (Collapse) | Author |
|---|
|
This references the database schemas known from the past with integer
values internally. 0 is used for an empty database and 1 for what was
used in ceres version 0.4.0.
The old approach to write the `git describe` output into the database
worked well for released versions but was problematic during
development. A numerical and separate database schema versioning is
easier to handle.
|
|
|
|
Reducing global variables makes it easier to understand functions
independently of the rest of the code.
Adding the new model.DB type as a custom variant of the sql.DB type
makes it possible to write methods for the database which makes the code
way more readable.
|
|
This new package is only for database migrations. All data for Ceres
should be stored inside the SQLite3 database. Thus migrations can always
be executed with functions with the following signature.
func(tx *sql.Tx) error
Those migration functions should be stored inside the new package.
Bigger SQL code can be stored in *.sql files for better syntax
highlighting. This code is embedded into the final Go executable by
using the embed package.
|
|
The default use case should be to not inject example recipes.
|
|
This makes the code easier to understand because there is an executable
version and a database version handled inside that file.
|
|
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.
|
|
|
|
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.
|
|
An empty database requires to add the metadata table with the version
entry to make migrations possible. Thus this detection will be required.
|
|
This makes it more clear that the full migration will be rolled back on
errors.
|
|
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
|
|
|
|
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
|
|
|
|
|
|
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.
|
|
This provides the infrastructure to create views and HTTP handlers to
provide recipe steps.
|
|
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.
|
|
This allows to formulate the test data with an object-based model which
is easier than writing it down in a relational model.
|
|
This is useful for debugging and testing.
|
|
This provides the basic table structure to the database.
|
|
The already implemented storage folder should contain a sqlite database
to store most parts of the Ceres user data.
|
