Design: Fixtures

Author: Stuart Douglas

Description (what)

Fixtures will allow users to pre-seed the system with values in dev mode, to allow things like default users etc to be setup.

Motivation (why, optional)

End users will not want to start from a blank database each time, our lack of fixtures will be one of the first things end users run into when writing applications with databases.

Goals

• Allow for the FTL dev database to be pre-seeded with data

Non-Goals (optional)

• No test support yet, as we don't have a DB testing strategy yet

Design (how)

We will introduce the concept of fixture verbs, which are verbs that are called on startup in development mode. These verbs can never be called when not in dev mode, so cannot be run in production. They do not have clients generated, and cannot be called from code, although they can be called from the console or CLI.

Generall these fixture verbs will be called by the provisioner in dev mode once the module has started, although it is possible to opt out of this behaviour if they are intended for manual use.

Fixtures will not appear in the production schema, they are only present in the schema when running ftl dev.

In future we may want to make fixtures a first class feature in the schema, however that is out of scope of this initial implementation.

Implementation

In go fixtures will be defined using //ftl:fixture manual? (database <dbname>)?, in the JVM they will be defined using a similar annotation. Fixtures must not accept a request type or define a response type. The fixture has two options that affect it's behaviour:

• manual if the fixture is defined as a manual fixture then it is not run at startup, and can only be run through the console or CLI
• database if a database is defined then the fixture is only run if the named database has had migrations run, if the DB has not been modified then the fixture is not run. Note that this means that changes to the fixture itself are not propagated automatically, we will likely need some kind of 'recreate' command in the future.

Fixtures will be invoked by the dev provisioner, and are effectivly another provisionable resource.