<feed xmlns='http://www.w3.org/2005/Atom'>
<title>ceres/model/object.go, branch step-re-ordering</title>
<subtitle>Recipe server for your favorite dishes</subtitle>
<id>https://cgit.xengineering.eu/ceres/atom/model/object.go?h=step-re-ordering</id>
<link rel='self' href='https://cgit.xengineering.eu/ceres/atom/model/object.go?h=step-re-ordering'/>
<link rel='alternate' type='text/html' href='https://cgit.xengineering.eu/ceres/'/>
<updated>2026-08-13T19:15:49Z</updated>
<entry>
<title>WIP: Add JSON-based API under `/api`</title>
<updated>2026-08-13T19:15:49Z</updated>
<author>
<name>xengineering</name>
<email>me@xengineering.eu</email>
</author>
<published>2026-08-13T18:53:24Z</published>
<link rel='alternate' type='text/html' href='https://cgit.xengineering.eu/ceres/commit/?id=60bdc926dd7235fd55930ebd5b30c2e346f8ca59'/>
<id>urn:sha1:60bdc926dd7235fd55930ebd5b30c2e346f8ca59</id>
<content type='text'>
TODO: Not all the information is provided there.

This commit provides an unstable JSON API for communication with an
upcoming Dart frontend.

Later it might be part of the public interface for integration into
other services. For this step it has to be ensured the semantics are not
changing a lot in the future which is currently out of scope.
</content>
</entry>
<entry>
<title>Introduce model.Transaction()</title>
<updated>2024-05-08T20:26:00Z</updated>
<author>
<name>xengineering</name>
<email>me@xengineering.eu</email>
</author>
<published>2024-05-08T19:53:13Z</published>
<link rel='alternate' type='text/html' href='https://cgit.xengineering.eu/ceres/commit/?id=0ba1a7661a81200db98e40149eef1e39fd22f407'/>
<id>urn:sha1:0ba1a7661a81200db98e40149eef1e39fd22f407</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>model: Add helper function for safe CRUD</title>
<updated>2024-04-07T08:47:36Z</updated>
<author>
<name>xengineering</name>
<email>me@xengineering.eu</email>
</author>
<published>2024-04-07T08:42:03Z</published>
<link rel='alternate' type='text/html' href='https://cgit.xengineering.eu/ceres/commit/?id=c4a4a8b5f60a568abd2af614ca4a5d06855bc3a1'/>
<id>urn:sha1:c4a4a8b5f60a568abd2af614ca4a5d06855bc3a1</id>
<content type='text'>
This removes the redundant setup of a database/sql.Tx in each HTTP
handler.
</content>
</entry>
<entry>
<title>model: Add model.Object interface</title>
<updated>2024-04-07T08:26:20Z</updated>
<author>
<name>xengineering</name>
<email>me@xengineering.eu</email>
</author>
<published>2024-04-06T18:56:49Z</published>
<link rel='alternate' type='text/html' href='https://cgit.xengineering.eu/ceres/commit/?id=537bbcea3b2477eeae7d86422a073558185cf4eb'/>
<id>urn:sha1:537bbcea3b2477eeae7d86422a073558185cf4eb</id>
<content type='text'>
This interface will allow to implement generic functions based on the
Object interface which covers the four CRUD methods create, read, update
and delete.

This should be possible for every object handled by the server.
</content>
</entry>
</feed>
