ceres/model, branch exchange-format

model: Implement favorite recipes

2024-11-03T15:05:55Z

This adds the ability to store a flag `is_favorite` inside the database. The corresponding SQL migration is part of this commit. Furthermore the Go code in the model package is adapted.

view: Order ingredient summary by ingredient name

2024-10-24T18:14:14Z

This makes it easier to write a shopping list for the required ingredients.

Rework error handling of model.DB.Transaction()

2024-10-24T15:01:24Z

The functions in the sub-packages model, view and controller should not log too much. Instead they should return errors which can be extended by fmt.Errorf(": %w", err).

Fix unit tests

2024-10-23T16:42:20Z

API changes were not adopted in the unit tests.

model: Rename to db.go

2024-10-21T19:37:54Z

The old name database.go did not match the type name DB.

model: Refactor public API of DB

2024-10-21T19:34:31Z

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 DB

2024-10-21T19:34:26Z

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: Handle schema versions internally by integers

2024-10-15T18:25:38Z

This references the database schemas known from the past with integer values internally. 0 is used for an empty database and 1 for what was used in ceres version 0.4.0. The old approach to write the `git describe` output into the database worked well for released versions but was problematic during development. A numerical and separate database schema versioning is easier to handle.

model: Simplify DB method signatures

2024-10-13T18:21:00Z

model: Replace global db variable by custom type

2024-10-13T17:55:38Z

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.

Introduce xengineering.eu/ceres/model/migrations

2024-10-13T16:54:18Z

This new package is only for database migrations. All data for Ceres should be stored inside the SQLite3 database. Thus migrations can always be executed with functions with the following signature. func(tx *sql.Tx) error Those migration functions should be stored inside the new package. Bigger SQL code can be stored in *.sql files for better syntax highlighting. This code is embedded into the final Go executable by using the embed package.

model: Fix direct access to database

2024-10-12T13:24:33Z

Instead a database transaction has to be used. Each database interaction should be wrapped into a transaction to make sure any possible change (even side-effects) can be rolled back in case of errors.

Apply go fmt to all source files

2024-09-11T18:25:54Z

This applies default Go code style recommendations.

model: Add strict Ingredient.Validate()

2024-05-17T21:20:41Z

model: Add strict Step.Validate()

2024-05-17T21:16:36Z

model: Fix another unhandled error

2024-05-17T21:15:56Z

This could also lead to bugs.

model: Fix ignored error

2024-05-17T21:10:17Z

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 validation

2024-05-17T15:14:40Z

This reduces code duplication and enforces time stamps.

model: Make Recipe.Validate() more strict

2024-05-15T18:09:35Z

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 page

2024-05-12T18:52:25Z

view: Show ingredients on read page

2024-05-12T18:52:25Z

model: Add per-step ingredients

2024-05-12T18:52:25Z

Inject examples only with new --example flag

2024-05-09T20:37:03Z

The default use case should be to not inject example recipes.

model: Fix unit tests

2024-05-09T20:23:28Z

model: Rename version to execVersion

2024-05-09T20:12:54Z

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 DB

2024-05-09T20:04:06Z

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 databases

2024-05-09T19:59:01Z

model: Initial database version injection

2024-05-09T19:48:56Z

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 empty

2024-05-09T19:31:19Z

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 transaction

2024-05-09T19:10:50Z

This makes it more clear that the full migration will be rolled back on errors.