<feed xmlns='http://www.w3.org/2005/Atom'>
<title>ceres/model/sql, branch exchange-format</title>
<subtitle>Recipe server for your favorite dishes</subtitle>
<id>https://cgit.xengineering.eu/ceres/atom?h=exchange-format</id>
<link rel='self' href='https://cgit.xengineering.eu/ceres/atom?h=exchange-format'/>
<link rel='alternate' type='text/html' href='https://cgit.xengineering.eu/ceres/'/>
<updated>2024-11-03T15:05:55Z</updated>
<entry>
<title>model: Implement favorite recipes</title>
<updated>2024-11-03T15:05:55Z</updated>
<author>
<name>xengineering</name>
<email>me@xengineering.eu</email>
</author>
<published>2024-11-03T14:49:43Z</published>
<link rel='alternate' type='text/html' href='https://cgit.xengineering.eu/ceres/commit/?id=7cd3a096a975801a07fb3ff06b6fac70e17234ce'/>
<id>urn:sha1:7cd3a096a975801a07fb3ff06b6fac70e17234ce</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>model: Save int-based schema version in DB</title>
<updated>2024-10-21T19:34:26Z</updated>
<author>
<name>xengineering</name>
<email>me@xengineering.eu</email>
</author>
<published>2024-10-15T19:23:10Z</published>
<link rel='alternate' type='text/html' href='https://cgit.xengineering.eu/ceres/commit/?id=118e1c69057e4e7b6ab3e730d5628b4822ed4c4d'/>
<id>urn:sha1:118e1c69057e4e7b6ab3e730d5628b4822ed4c4d</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>Introduce xengineering.eu/ceres/model/migrations</title>
<updated>2024-10-13T16:54:18Z</updated>
<author>
<name>xengineering</name>
<email>me@xengineering.eu</email>
</author>
<published>2024-10-13T12:08:26Z</published>
<link rel='alternate' type='text/html' href='https://cgit.xengineering.eu/ceres/commit/?id=ed19b82335345833c5b8f5446237d559a3657a35'/>
<id>urn:sha1:ed19b82335345833c5b8f5446237d559a3657a35</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>model: Add per-step ingredients</title>
<updated>2024-05-12T18:52:25Z</updated>
<author>
<name>xengineering</name>
<email>me@xengineering.eu</email>
</author>
<published>2024-04-04T12:54:21Z</published>
<link rel='alternate' type='text/html' href='https://cgit.xengineering.eu/ceres/commit/?id=87ae71413e47ef34da57bc1e0b8dddbf84b0c66a'/>
<id>urn:sha1:87ae71413e47ef34da57bc1e0b8dddbf84b0c66a</id>
<content type='text'>
</content>
</entry>
<entry>
<title>model: CRUD methods only for targeted objects</title>
<updated>2024-04-06T18:22:04Z</updated>
<author>
<name>xengineering</name>
<email>me@xengineering.eu</email>
</author>
<published>2024-04-06T16:45:49Z</published>
<link rel='alternate' type='text/html' href='https://cgit.xengineering.eu/ceres/commit/?id=4aee2c3b45caa890537a0fc0c850c4523a4eb56c'/>
<id>urn:sha1:4aee2c3b45caa890537a0fc0c850c4523a4eb56c</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>model: Add recipe steps</title>
<updated>2024-03-24T09:10:54Z</updated>
<author>
<name>xengineering</name>
<email>me@xengineering.eu</email>
</author>
<published>2024-03-10T09:59:23Z</published>
<link rel='alternate' type='text/html' href='https://cgit.xengineering.eu/ceres/commit/?id=ddc6e8e1fb8a4b1dfe8421b12e40b15162ae75f1'/>
<id>urn:sha1:ddc6e8e1fb8a4b1dfe8421b12e40b15162ae75f1</id>
<content type='text'>
This provides the infrastructure to create views and HTTP handlers to
provide recipe steps.
</content>
</entry>
<entry>
<title>model: Create test data with Go instead of SQL</title>
<updated>2024-03-04T19:33:58Z</updated>
<author>
<name>xengineering</name>
<email>me@xengineering.eu</email>
</author>
<published>2024-03-03T19:06:40Z</published>
<link rel='alternate' type='text/html' href='https://cgit.xengineering.eu/ceres/commit/?id=b62c686702622b747ab082b7b12b3e611e1d7e1f'/>
<id>urn:sha1:b62c686702622b747ab082b7b12b3e611e1d7e1f</id>
<content type='text'>
This allows to formulate the test data with an object-based model which
is easier than writing it down in a relational model.
</content>
</entry>
<entry>
<title>model: Switch to very basic database schema</title>
<updated>2024-02-11T19:03:15Z</updated>
<author>
<name>xengineering</name>
<email>me@xengineering.eu</email>
</author>
<published>2024-02-06T18:58:49Z</published>
<link rel='alternate' type='text/html' href='https://cgit.xengineering.eu/ceres/commit/?id=30303b34012f22cbe898dcebfd460709b206181d'/>
<id>urn:sha1:30303b34012f22cbe898dcebfd460709b206181d</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>model: Inject test data into database</title>
<updated>2023-12-27T12:05:05Z</updated>
<author>
<name>xengineering</name>
<email>me@xengineering.eu</email>
</author>
<published>2023-12-27T12:04:26Z</published>
<link rel='alternate' type='text/html' href='https://cgit.xengineering.eu/ceres/commit/?id=8ce328fafd9b2ad152f0afc16176cf01e1e66669'/>
<id>urn:sha1:8ce328fafd9b2ad152f0afc16176cf01e1e66669</id>
<content type='text'>
This is useful for debugging and testing.
</content>
</entry>
<entry>
<title>model: Add initial SQL migration</title>
<updated>2023-12-27T11:42:25Z</updated>
<author>
<name>xengineering</name>
<email>me@xengineering.eu</email>
</author>
<published>2023-12-27T11:39:10Z</published>
<link rel='alternate' type='text/html' href='https://cgit.xengineering.eu/ceres/commit/?id=e7bbadc8f469d5cbfbc012932c83d1d440b6e8a3'/>
<id>urn:sha1:e7bbadc8f469d5cbfbc012932c83d1d440b6e8a3</id>
<content type='text'>
This provides the basic table structure to the database.
</content>
</entry>
</feed>
