| Age | Commit message (Collapse) | Author |
|---|
|
In addition to the enforcement of titles in the model package the HTML
form field for the title is set to 'required' to give the user feedback
via the browser that a title is required.
|
|
If a recipe has no title it is hard to reference in the front end.
Especially the /recipes page makes problems in that case since it is
impossible to click on that recipes and thus also to remove it.
|
|
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
|
|
This makes it easier to run unit tests.
|
|
|
|
This variable will be the only used representation for version
information. It can trivially be used for an equality check. Further
data as semantic versioning must be parsed from this string.
|
|
This improves readability of the main() function.
|
|
This makes it unnecessary to call this functionality from main().
|
|
|
|
This separates the main control flow and HTTP-related high-level code.
Furthermore the new main.Server type makes the related methods and
function more like the functions from the standard library with a
NewServer() function and methods with only one word as name.
|
|
The intention of this file was that a Ceres executable could compare its
version with the version of the storage folder.
If the versions match the storage folder could be directly used. If the
storage version is lower the executable can apply migrations to the
storage folder until the versions match.
The problem is that executing migrations inside the database and
updating the version.txt cannot be atomic.
In contrast the version string could be saved inside the database itself
in a metadata table. In that case the migration together with the update
of the version string can be executed inside one database transaction
which guarantees atomicity.
The problem could still be that migrations should be applied also to the
files and folders inside the storage folder. This problem can only be
avoided by not using files to store data and instead use the BLOB
datatype if necessary.
Even in case of a future filesystem use it is still better to have the
guarantee that the database with file paths and metadata and the there
included version string are in sync.
|
|
It is a common pattern inside the Go standard library to provide a
constructor with this naming scheme to custom types of the package.
Doing this here results in a style closer to the standard library which
improves readability.
|
|
The model package where this used to be implemented should not care too
much about logging. Furthermore it is easier to compare the log output
with the main() function if the log statements are there.
|
|
This makes it easier to read the logs and follows the pattern to move
log messages more to the main() function instead of spreading them
accross the whole code base.
|
|
These new methods provide essential functionality related to the storage
folder.
|
|
This new type definition will make it easier to handle the storage
directory of Ceres and related functionality which can be implemented
with methods.
|
|
The missing submodule init / update caused build issues because the
external simple.css file could not be included.
|
|
|
|
This aspect of Ceres is also part of the public API. A breaking change
in the configuration file format will require a version change which
indicates that.
|
|
|
|
This ensures that Ceres is never executed without Git version
information. This removes the requirement to check for this on every
use. To ensure the server does not work with an incompatible storage
directory it is in every case needed to know the exact version of the
running executable.
|
|
This re-enables config file support.
|
|
This is not useful in production. Furthermore in the debug use case the
default storage path is now ./storage which can easily be removed by `rm
-rf storage`. This also allows to not remove the storage folder for
further analysis of the storage folder.
|
|
|
|
|
|
|
|
This prepares configuration file support.
|
|
This is required according to semver.org.
|
|
This prepares the ability to check for compatibility between a Ceres
executable build and an existing storage folder.
|
|
This allows to get the server version via HTTP. The output of `git
describe --dirty --always` and a line break is returned together with
HTTP 200.
If the server build contains no version information an error message and
HTTP 404 is returned.
|
|
This allows to identify the version of a Ceres executable build.
|
|
The output of `git describe --dirty --always` is passed as a string via
Go build flags.
|
|
Using a build system like Make allows to execute more complex builds
while the user interface is still simple. The Makefile added by this
commit is just a basic starting point.
|
|
|
|
This is expected functionality for a command line application.
|
|
This removes the redundant setup of a database/sql.Tx in each HTTP
handler.
|
|
This interface will allow to implement generic functions based on the
Object interface which covers the four CRUD methods create, read, update
and delete.
This should be possible for every object handled by the server.
|
|
A create, read, update or delete (CRUD) method should only care about
the object which provides the receiver and the relations to its child
objects.
For example the method
func (r *Recipe) Create(tx *sql.Tx) error {}
should only create the relational data inside the database for the
recipe, not for the steps nested into this Recipe struct. This should be
covered by the
func (s *Step) Create(tx *sql.Tx) error {}
method which is then called by `func (r *Recipe) Create()`.
This has the advantage that every CRUD method has a constraint scope and
is more unified since the Step CRUD methods now have a Step struct as
receiver instead of a Recipe receiver.
|
|
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.
|
|
It should be inside the body tag but used to be before it.
|
|
Design changes should be avoided for now since simple.css cares about
the CSS part of Ceres.
|
|
The model package should never modify the data. Thus the functionality
to update timestamps is moved to the controller package which is
intended to modify data.
|
