feat: inject DB verb resources

[worstell]

you can declare a DB by defining a type that implements PostgresDatabaseConfig (the only supported interface implementing DatabaseConfig, at present):

type MyConfig struct {}

// name provides the DB name
func (MyConfig) Name() string { return "testdb" }

// tags the type as a DB decl
func (MyConfig) db()

// tags the DB type as `postgres`
func (MyConfig  pgdb()

to avoid the verbosity of implementing db() and pgdb(), you can instead embed ftl.DefaultPostgresDatabaseConfig.
this will implement these "tag" methods but not any required methods, e.g. Name() which must be explicitly provided in the user code.

type MyConfig struct {
   ftl.DefaultPostgresDatabaseConfig
}

// name provides the DB name
func (MyConfig) Name() string { return "testdb" }

you can then use the DB you've configured by injecting a handle around its config into a verb signature:

//ftl:verb
func Query(ctx context.Context, in Request, db ftl.DatabaseHandle[MyConfig]) (Response, error) {
  db.Get(ctx).Exec(...)
  // ...
}

eventually we will extend DatabaseConfig with additional methods, e.g. RAM, disk, max connections, etc.

[alecthomas]

I can't review this fully at the moment, but is it possible for us to eliminate the string names now we're code-genning? They were only present because we needed them at runtime, but that is no longer the case and they are a source of errors.

[alecthomas]

ie. we use the variable name as the name, similar to what we do with eg. verb function names.

[worstell]

ie. we use the variable name as the name, similar to what we do with eg. verb function names.

the pattern for these are type alias declarations, e.g. type TestDb = ftl.PostgresDatabaseHandle

the limitation was that, afaik, using reflection at runtime we can't derive the alias name because unlike the pattern type TestDb ftl.PostgresDatabaseHandle, no new named type is declared, and the reflected type is always just ftl.PostgresDatabaseHandle. we can still get the alias name during static analysis, but just not at runtime (unless i'm mistaken).

type TestDb ftl.PostgresDatabaseHandle doesn't work because we need to supply member functions, e.g. .Get(ctx). i considered embedding but that just felt so much less ergonomic/intuitive and the string handling is mostly isolated to code-genned files, except unfortunately in ftltest.

[alecthomas]

we can still get the alias name during static analysis, but just not at runtime (unless i'm mistaken).

I was more suggesting changing to this:

var myDb = ftl.PostgresDatabase()

We'd register the variable with the statically extracted name "myDb" removing the redundancy/confusion of having to do:

var myDb = ftl.PostgresDatabase("myDb")

[worstell]

we can still get the alias name during static analysis, but just not at runtime (unless i'm mistaken).

I was more suggesting changing to this:

var myDb = ftl.PostgresDatabase()

We'd register the variable with the statically extracted name "myDb" removing the redundancy/confusion of having to do:

var myDb = ftl.PostgresDatabase("myDb")

using a type rather than a variable lets us pass the db decl into the verb signature like we're doing for the verb clients, e.g.

type TestDb = ftl.PostgresDatabaseHandle

//ftl:verb export
func Echo(ctx context.Context, req Request, db TestDb) (Response, error) {
	db.Get(ctx).Exec(...)
}

[alecthomas]

We're going to need a solution to this sooner or later. At some point the databases are going to have configuration options, eg. to set the instance size. If we can't uniquely identify a database handle we won't be able to identify the configuration for that handle.

ie. each database will be configurable with the RAM/CPU size