DB Migrations (Even with GORM)

[jacobconley]

Gorm's approach

Gorm has the auto migrator, which is quite different from the traditional solution.

Pros:

• Doesn't really need anything other than the model
• The user deals with it themselves - we really don't have to do anything. Though that calls into question whether we should even make the ORM a part of this project at all. Having an existential crisis here

Foreign key constraints can be made explicit manually - it's a lil clunky but par for the course

Cons:

• No rollbacks or schema output out of the box
• User has to configure migrations in code instead of being able to use the existing configurations and just run a simple cli command
• Kinda scary I think!

Alternatives

I could do some sketchy reflection nonsense to make some sort of configurable automigrate command. Gotta look more into what I can configure as strings via reflection

Traditional migrations

• gormigrate - golang migrations, but admits it's not quite as ready to scale
• golang-migrate - SQL migrations in another implementation
• But at this point why not stick with Soda? Already implemented, supports the SQL migrations ^ plus Fizz if you want it. All we would have to do is implement the migrations table

Fizz

Pros

• less of a pain in the arse than defining them in golang

Cons

• kinda niche thing. but it's wholly optional anyways AND supports embedded SQL
• not as beautiful as it could be! but maybe we can make our own some day

[jacobconley]

Doesn't seem to be a way to get a reflection type from a name as string. Probably for the better. We could do some wacky codegen from the TOML config nonetheless? Gets more and more suspect the more I think about it.

More or less three options right now:

• Ignore altogether, perhaps dropping the ORM feature from the project entirely
  • I reckon for GORM auto-migrate, the user just writes a migrate.go for themselves
• Keep our current wrapper around Soda, maybe expand on it
• Making our own automigrate with the above nonsense

I suppose we can keep going with Soda, bearing in mind we may scrap it altogether - though probably unlikely. We can just build onto the codegen replacing Genny, and perhaps we end up going more into that third option

[jacobconley]

How will it work for middleware type things, like a CMS that needs to update? Probably want defined SQL-ish migrations instead of automatic migrations right? I mean how would you even trigger automatic ones