| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
