| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
This provides the infrastructure to create views and HTTP handlers to
provide recipe steps.
|
|
This allows to formulate the test data with an object-based model which
is easier than writing it down in a relational model.
|
|
This simple model is used to test if it is helpful to implement the four
CRUD methods create, read, update and delete all inside the model
package.
The model package should also provide the datastructures for these
operations (well suited for the required views) aswell as tests for
them.
With this approach it should be possible to easily implement the view
and controller package because most of the logic is already inside the
model package and is tested.
|
|
This is useful for debugging and testing.
|
|
This provides the basic table structure to the database.
|
