Replace GORM with ent

[omarkohl]

gorm.io entgo.io

This was initially attempted in commits:

• d96bc55 test: always use UTC time stamps to avoid errors
• db51556 docs: document changes due to ent (replacing GORM)
• e4275a9 refactor(cleosrv): remove obsolete model.go
• 9c47f01 feat(cleosrv): allow Estimate.Reason to be left empty
• 2450379 refactor(frontend): add support for new ent-based GraphQL schema
• 814e7ab refactor(cleoc): make it compatible with new ent
• 248d96a refactor(cleosrv): use Ent to define DB model and generate schema
• 2d99ce4 build: ensure cleosrv code is generated first to update GraphQL schema

but undone in commit 5f39afbf31 because it needs some more design in a separate branch.

The biggest downside is that the resulting GraphQL schema is too tightly coupled to the DB. In particular the input types allow passing more information than I want e.g. I don't want CreateForecastInput to include EstimateIDs because I want to create the initial estimate together with the forecast (same DB transaction) and I don't want the client to first create the Estimate and then the Forecast. I implemented this correctly anyway in the mutation, but the type still exposes the params and I don't see an easy way to limit this.

Atlas, the DB migration tool most tightly coupled to ent does not support including the DB migrations directly in the code/binary but instead expects them to be in a directory. Therefore using golang-migrate is probably unavoidable.

Another downside of ent is that I would be forced to already execute the first DB migration because the DB schema is slightly different than what GORM generates, even though I am trying to achieve the same.

There is also no native support for the Go-only SQLite implementation modernc.org/sqlite, requiring some sql.Register() magic to make it work.

There also seems to be some weird bug where timestamps stored in the DB can't be read back if they are not in the current timezone or something like that. I didn't dig really deeply into it. Probably an issue in the interplay of ent and SQLite. Forcing everything to be in UTC would probably work around this.

Despite this, ent could still be really valuable because it makes development faster.

Ent does have a few very nice features such as the way of specifying the DB model with strong typing and the privacy layer. Maybe keeping ent just as an ORM but without generating GraphQL schema from it would be a good option.

[omarkohl]

The ent-experiment branch contains a revert of the revert and can be used to experiment with ent.