ceres/main.go, branch step-re-orderingRecipe server for your favorite disheshttps://cgit.xengineering.eu/ceres/atom/main.go?h=step-re-ordering2024-10-21T19:34:31Zmodel: Refactor public API of DB2024-10-21T19:34:31Zxengineeringme@xengineering.eu2024-10-21T19:30:12Zurn:sha1:72601b87ef040a3c6882368ac85c12c1ae705cd2
This commit makes not externally needed methods private and adds error
return values since something like log.Fatal() should be called outside
this package since it is control-flow-related.
model: Save int-based schema version in DB2024-10-21T19:34:26Zxengineeringme@xengineering.eu2024-10-15T19:23:10Zurn:sha1:118e1c69057e4e7b6ab3e730d5628b4822ed4c4d
Ceres v0.4.0 used the `git describe` output as database schema and
enforced exactly matching versions between the database and the
executable.
This turned out to be not flexible enough. It is way easier to version
the database separately with a simple integer and require the same
database schema version integer between the application and the
database.
This commit implements this new approach.
model: Replace global db variable by custom type2024-10-13T17:55:38Zxengineeringme@xengineering.eu2024-10-13T17:52:28Zurn:sha1:473052ed8f2c83052ed5b47a7f4cec68ac2621a6
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.
Apply go fmt to all source files2024-09-11T18:25:54Zxengineeringme@xengineering.eu2024-09-11T18:25:31Zurn:sha1:54029aac92f17ec87d3ef0bb73fcdac271b209c9
This applies default Go code style recommendations.
Move config path from config to flags struct2024-05-11T22:12:55Zxengineeringme@xengineering.eu2024-05-11T22:12:55Zurn:sha1:642fed1cbf5160c89a93deab810bd44fb49d2a4a
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.
Group flag variables in struct2024-05-11T22:03:56Zxengineeringme@xengineering.eu2024-05-11T22:03:56Zurn:sha1:938ab103727688b73f2d7b3ef4d9e1b1c85c6628Inject examples only with new --example flag2024-05-09T20:37:03Zxengineeringme@xengineering.eu2024-05-09T20:33:42Zurn:sha1:0ac3cc76b4b6c824c4b3f7a357d40b487984abfb
The default use case should be to not inject example recipes.
Add version to log output2024-05-09T20:10:30Zxengineeringme@xengineering.eu2024-05-09T20:10:30Zurn:sha1:228fca961ca0a2d38a61f40fee2a484e1d5190f1model: Initial database version injection2024-05-09T19:48:56Zxengineeringme@xengineering.eu2024-05-09T19:48:56Zurn:sha1:ca96df29085f9ca6567cd474d0920e48c6410b42
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.
Restructure database-related functions2024-05-09T08:02:00Zxengineeringme@xengineering.eu2024-05-09T08:02:00Zurn:sha1:a2038b0ea35d1466c84e6e04a2e4597fc038815aRename gitDescribe to version2024-05-08T18:59:41Zxengineeringme@xengineering.eu2024-05-08T18:59:41Zurn:sha1:5a09313066f5594ca9e3917c00821e443dcba7bc
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.
Introduce await() function2024-05-07T19:43:28Zxengineeringme@xengineering.eu2024-05-07T19:43:28Zurn:sha1:0368b6d0f7069be078ca6dba2c8bb3ed06d9f03a
This improves readability of the main() function.
view: Use init() function to parse templates2024-05-07T19:35:40Zxengineeringme@xengineering.eu2024-05-07T19:35:40Zurn:sha1:5b3f0a81abea93b198825b5537297f3f04d1f7c1
This makes it unnecessary to call this functionality from main().
model: Init database with database path2024-05-07T19:25:19Zxengineeringme@xengineering.eu2024-05-07T19:25:19Zurn:sha1:75c1270c86ac17d056161714ac32a57113696d21Move HTTP server code to new server.go file2024-05-07T18:54:33Zxengineeringme@xengineering.eu2024-05-07T18:54:33Zurn:sha1:ebb446f6115b4ca690ea354fa4275e33a0d9976b
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.
model: Do not write version.txt inside storage2024-05-06T19:42:07Zxengineeringme@xengineering.eu2024-05-06T19:42:07Zurn:sha1:5f5626314a40a47f53773f386e90e3bb6adfa96a
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.
model: Introduce NewStorage() function2024-05-06T19:16:22Zxengineeringme@xengineering.eu2024-05-06T15:16:54Zurn:sha1:250fc80c3c15cd38a518af5c256e2ba619295f5f
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.
Move storage path logging to main() function2024-05-04T18:52:02Zxengineeringme@xengineering.eu2024-05-04T18:48:43Zurn:sha1:5c248884afa530bafb7b04dc14c587e3029480f6
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.
Add explicit startup / shutdown log messages2024-05-04T18:52:02Zxengineeringme@xengineering.eu2024-05-04T18:28:43Zurn:sha1:5260a38bab0dd77846318802edeb6a7ecd462a56
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.
model: Add storage.Exists() and storage.Create()2024-05-04T18:22:23Zxengineeringme@xengineering.eu2024-05-04T18:22:23Zurn:sha1:c6fbbbded8463fc94e5af223246eac97d538a9e5
These new methods provide essential functionality related to the storage
folder.
model: Introduce type Storage2024-05-04T18:07:35Zxengineeringme@xengineering.eu2024-05-04T18:07:35Zurn:sha1:7d8899e1d2bf45511d10670dd9a6ad386afb8da1
This new type definition will make it easier to handle the storage
directory of Ceres and related functionality which can be implemented
with methods.
Make build-time version information mandatory2024-05-01T12:52:21Zxengineeringme@xengineering.eu2024-05-01T12:50:33Zurn:sha1:07f011bbbb22de9e7b4fd4af30fa0a92ee25b6d8
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.
Add --config flag2024-05-01T11:58:54Zxengineeringme@xengineering.eu2024-05-01T11:58:54Zurn:sha1:1e2a3377e43786e25dc03b8612513d47f8dfb3c6
This re-enables config file support.
Do not remove storage folder2024-05-01T11:20:22Zxengineeringme@xengineering.eu2024-05-01T11:20:22Zurn:sha1:390642f9bbc12f0b435f343fc35f4a47c5ec7680
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.
Use default storage path instead of temp dir2024-05-01T11:19:05Zxengineeringme@xengineering.eu2024-05-01T11:19:05Zurn:sha1:4cc0677b79edeed05ead23def152ac45f35f556dUse default config for HTTP address2024-05-01T11:09:39Zxengineeringme@xengineering.eu2024-05-01T11:09:39Zurn:sha1:f9117c3740a134ce544f5a70bcf5b5da06d976damodel: Add version.txt file to storage folder2024-05-01T09:22:13Zxengineeringme@xengineering.eu2024-05-01T09:21:04Zurn:sha1:7cbe33ae59757d67a6b31030aef0769f86acf3c2
This prepares the ability to check for compatibility between a Ceres
executable build and an existing storage folder.
view: Add /version endpoint2024-05-01T08:56:26Zxengineeringme@xengineering.eu2024-05-01T08:56:26Zurn:sha1:d982951ec15326487eefa80261a0f466d64e2ba0
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.
Add --version flag2024-05-01T08:32:34Zxengineeringme@xengineering.eu2024-04-30T18:52:41Zurn:sha1:01699e3c9339cd7880f632be088d770225b84d68
This allows to identify the version of a Ceres executable build.
Add command line help page2024-04-30T17:52:59Zxengineeringme@xengineering.eu2024-04-24T19:13:05Zurn:sha1:7fd4cc40980c51221af5ca0c3c3cc6ee301632f7
This is expected functionality for a command line application.