Is FSL not intended to manage child databases?

[rcausey]

I was looking into using FSL to manage the schema documents for my databases, but it appears that there is no FSL object for a child database. In addition, when I use the fauna shell to pull the FSL files for an existing database that has children underneath it, it does not generate any FSL definitions for the child databases. Is FSL not intended to manage child databases?

[ptpaterson]

You cannot define child databases directly in an FSL file, but you can place the FSL files for your database and child databases in separate directories in order to manage them.

There are two major cases that I am thinking of that FSL and the Fauna shell CLI can help with, which I will detail below.

Are there cases where you still think that defining a child database in .fsl files would help you? Or is it more that you were hoping to namespace schema for the children under the parent FSL in some way?

Multiple application environments

This is a case where a Fauna Project configuration can be helpful.

In this setup, we have:

• a primary database that can optionally hold any shared data between environments (or just be empty); and
• several child databases that represent development, staging, and production environments for the application.

Here is a view of a Javascript project I created that contains separate directories for .fsl files to define the primary project db and the environment databases. I’ve also added some scripts to my package.json file. This is not exclusive to Javascript of course, but I want to illustrate that the Fauna “project”

In the .fauna-project file, I have listed all of the databases as “environments”. When you push the .fsl files, you can specify which directory of files to push, and to which database to push them.

default=project

[environment.project]
endpoint=cloud-us
database=Project

[environment.dev]
endpoint=cloud-us
database=Project/ev

[environment.staging]
endpoint=cloud-us
database=Project/staging

[environment.prod]
endpoint=cloud-us
database=Project/prod

corresponding commands to run

  "scripts": {
    "push-schema:project": "fauna schema push --dir fauna/project",
    "push-schema:dev": "fauna schema push --dir fauna/env --environment dev",
    "push-schema:staging": "fauna schema push --dir fauna/env --environment staging",
    "push-schema:prod": "fauna schema push --dir fauna/env --environment prod"
  },

Multi-tenant (1 child DB per account)

This is not a good application for Fauna Project configuration, but you can still use FSL to manage the schema for all of those child databases.

To push.fsl files to a specific database, you can use the --secret option.

# 1. Set an env variable for the parent database admin key
export FAUNA_ADMIN_KEY=fnAFS_2FBfBVTk.....

# 2. create the database if necessary
fauna create-database Tenant1234 --secret $FAUNA_ADMIN_KEY

# 3. push the schema to Tenant1234. Scope the key to the child database.
fauna schema push --dir dir/to/fs/files --secret "${FAUNA_ADMIN_KEY}:Tenant1234:admin"

[rcausey]

I think the multiple application environments case is the most applicable here. What I was hoping to do was have a bit of infrastructure as code (IaC) to manage the child databases and their access keys. To make that work, I would need to be able to define child databases in FSL and futher apply schema using FSL to those child databases after their creation using a scoped key created from the parent key. This collection in the child database is needed in order to facilitate automatic access key rotation.

Then, the application that needed a child database would get access to the access key via secrets management solution, and could further apply migrations there as needed.

However, after looking at FSL behavior some more, I don’t think it would work even if it did support defining child databases. FSL schema push appears to be an all or nothing operation at the database level, so there can’t be multiple different namespaced migrations applied to the same database cleanly.