ceres/model, branch 0.4.0Recipe server for your favorite disheshttps://cgit.xengineering.eu/ceres/atom?h=0.4.02024-05-17T21:20:41Zmodel: Add strict Ingredient.Validate()2024-05-17T21:20:41Zxengineeringme@xengineering.eu2024-05-15T18:18:39Zurn:sha1:bc149ee58122effc9d4c035da2af3a7ec1f2f862model: Add strict Step.Validate()2024-05-17T21:16:36Zxengineeringme@xengineering.eu2024-05-15T18:18:13Zurn:sha1:f8f5d296f218f79646a54d3aed8d54fa9f8704c1model: Fix another unhandled error2024-05-17T21:15:56Zxengineeringme@xengineering.eu2024-05-17T21:15:56Zurn:sha1:5194ea4b29ffef0fe5206899243339cf109af41d
This could also lead to bugs.
model: Fix ignored error2024-05-17T21:10:17Zxengineeringme@xengineering.eu2024-05-17T21:08:05Zurn:sha1:5d5580285a366e37ac00a4e1a6f2f1bda853ff28
An ignored return value here caused a serious bug as soon as validation
for ingredients was tried. The validation could raise an error e.g. on a
negative amount for the ingredient. This error was ignored at the
changed line which resulted into deleted ingredients for the whole
recipe.
model: Rework recipe validation2024-05-17T15:14:40Zxengineeringme@xengineering.eu2024-05-17T15:12:50Zurn:sha1:5eca3267d37cdc51f775b5452727efebbb7e7e9e
This reduces code duplication and enforces time stamps.
model: Make Recipe.Validate() more strict2024-05-15T18:09:35Zxengineeringme@xengineering.eu2024-05-15T18:09:35Zurn:sha1:ae771a44c2ffe31dc1bd67a12b65849f7d7d2d11
Before the next release this method should be as strict as possible to
avoid cases where actually invalid enters databases.
view: Add ingredient overview to recipe read page2024-05-12T18:52:25Zxengineeringme@xengineering.eu2024-04-07T10:04:11Zurn:sha1:bf328dd38a28cf44cfa81c7f1dcd95936d2d0301view: Show ingredients on read page2024-05-12T18:52:25Zxengineeringme@xengineering.eu2024-04-07T09:56:20Zurn:sha1:01d97189d245300d65ca31d650dd868d1d1fc0d8model: Add per-step ingredients2024-05-12T18:52:25Zxengineeringme@xengineering.eu2024-04-04T12:54:21Zurn:sha1:87ae71413e47ef34da57bc1e0b8dddbf84b0c66aInject 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.
model: Fix unit tests2024-05-09T20:23:28Zxengineeringme@xengineering.eu2024-05-09T20:23:28Zurn:sha1:0142af99aba36241c276a56a088e7aac10c62f86model: Rename version to execVersion2024-05-09T20:12:54Zxengineeringme@xengineering.eu2024-05-09T20:12:54Zurn:sha1:f7fca11c47224ff28b10a7f41fb76ce0404a0236
This makes the code easier to understand because there is an executable
version and a database version handled inside that file.
model: Require same version for executable and DB2024-05-09T20:04:06Zxengineeringme@xengineering.eu2024-05-09T20:04:06Zurn:sha1:0e8a199d6144fcfab05eb0c8a793073bc53783be
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.
model: Migrate only in empty databases2024-05-09T19:59:01Zxengineeringme@xengineering.eu2024-05-09T19:59:01Zurn:sha1:e5d57f2c4a9f01ac7a2b11c04b932311bd240611model: 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.
model: Detect if database is empty2024-05-09T19:31:19Zxengineeringme@xengineering.eu2024-05-09T19:31:19Zurn:sha1:ca19c73b305932a4ef41d31787eabb25f9417a05
An empty database requires to add the metadata table with the version
entry to make migrations possible. Thus this detection will be required.
model: Wrap migration completely in transaction2024-05-09T19:10:50Zxengineeringme@xengineering.eu2024-05-09T19:10:15Zurn:sha1:2db08f564ddb38e80c79c9338047f4e8f3a977e8
This makes it more clear that the full migration will be rolled back on
errors.
model: Enforce recipe titles2024-05-09T10:07:48Zxengineeringme@xengineering.eu2024-04-22T19:50:26Zurn:sha1:0455da359b9fe36bd6808b7e506fe24e48257bea
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.
model: Use defer for tx.Rollback()2024-05-09T09:13:46Zxengineeringme@xengineering.eu2024-05-09T09:13:46Zurn:sha1:fd7ee91110cf1de780f3c46822dd69385b3b6318
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
Restructure database-related functions2024-05-09T08:02:00Zxengineeringme@xengineering.eu2024-05-09T08:02:00Zurn:sha1:a2038b0ea35d1466c84e6e04a2e4597fc038815aIntroduce model.Transaction()2024-05-08T20:26:00Zxengineeringme@xengineering.eu2024-05-08T19:53:13Zurn:sha1:0ba1a7661a81200db98e40149eef1e39fd22f407
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
Fix unit tests2024-05-08T19:20:39Zxengineeringme@xengineering.eu2024-05-08T19:20:39Zurn:sha1:9073adf62f2fa78190c8296c5f6f6c9fb1963063model: Init database with database path2024-05-07T19:25:19Zxengineeringme@xengineering.eu2024-05-07T19:25:19Zurn:sha1:75c1270c86ac17d056161714ac32a57113696d21model: 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.
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.
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:4cc0677b79edeed05ead23def152ac45f35f556d