| Age | Commit message (Collapse) | Author |
|---|
|
This is metadata about the config and thus does not belong to the config
itself. Moving it to the struct holding flag values is straight forward
since it is defined by flags.
|
|
|
|
The default use case should be to not inject example recipes.
|
|
|
|
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.
|
|
|
|
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.
|
|
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 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.
|
|
This is expected functionality for a command line application.
|
|
This allows to formulate the test data with an object-based model which
is easier than writing it down in a relational model.
|
|
|
|
This makes the update URL more consistent with the other ones. A check
ensures consistency of the URL and JSON ID values.
|
|
This reflects that these HTTP handler functions implement one of the
four CRUD methods create, read update and delete.
|
|
|
|
While forms can be send without JavaScript this new approach has the
benefit that the whole data is send as one JSON.
This JSON format can also be used for an API or testing.
|
|
|
|
Otherwise e.g. the Firefox browser throws an error on the console.
|
|
|
|
|
|
|
|
This is a simple first HTTP handler and is required to display the
website with the intended design.
|
|
This adds the infrastructure to add HTTP handlers. It already sets up
the HTTP server and makes sure it is started and stopped.
|
|
This is the intended behaviour for production and also for debugging to
at least inspect the data directory of Ceres.
|
|
The already implemented storage folder should contain a sqlite database
to store most parts of the Ceres user data.
|
|
This temporary directory is provided to store the user data for the
Ceres recipe server during development and testing.
|
|
Restarting from scratch seems to be the fastest approach to switch to
sqlite and get rid of some other structural mistakes from the past.
|
|
That way only the system user setup and ownership change has to be done
by the packager / installer.
|
|
Using a database is way more complex (see the commit statistics of this
commit) than using files to store recipe data. Also administration and
usage is simpler.
|
|
This makes templating easier and allows to use partial templates.
|
|
This auto-applies the recommended Go codestyle.
|
|
This has nothing to do with the database. Because the db is now a global
pointer the shutdown code can live in main.go.
|
|
Logging during a request is at the moment not really needed. Printing
the config to the log was a stupid idea too.
|
|
Passing the database pointer around is a lot of text and has no benefit.
|
