I have two top-level databases, one for development and one for production. Within each database, I have child-databases for each customer.
A feature I’m working on requires me to create a new collection within each child-database. From what I gathered in the docs, my understanding is I need to write migration code that roughly follows these steps:
Fetch a list of all child databases
Create a new Fauna Client for each child database with the correct server key
Create the collection
Is there a way I can do the above in the Shell using FQL? Related to that, what are best practices to deal with migrations in general?
You can use fauna-shell to perform the creation of the collection, but fauna-shell can only connect to a single database in a single session. There are no FQL statements that can switch keys or databases. You’ll have to manage keys and sessions with some sort of scripting.
Using an admin key from the parent database, you can build a scoped key that lets you access child databases. That way you can create collections in your child databases without having to create a key for each database. It’s basically just concatenating your key together with the name of the role you want to have in your child database:
You could use something like a shell script and the fauna-shell to query for your child databases and iterate over them, generate a scoped key, and use it to create your collections in each child database. Or you could use a host language like javascript to do it in (that’s the route I would take).
Finally, you may not even need child databases. If the collections in the child databases are all the same, and it’s just a matter of controlling access to the documents in those collections, then I’d recommend keeping things to a single database to simplify things.
Thanks guys, good to know that aligns with my findings as well .
I’ll keep my eyes on the fauna-schema-migrate project. This may come in handy!
Scoped keys looks interesting, I remember reading about that in the docs but was under the impression that’s to query child databases only, not to manipulate them. Reading your message, it sounds like that understanding isn’t correct so I’ll give that a go.
While I haven’t tested it, the reason I use child databases is so that customers can host them in their own account and bring their own Fauna server key (BYOK). This works in theory since all I need to connect to a DB is the key. I’m definitely curious to hear your thoughts on that.
Scoped keys are useful when administrators of a parent database need to access/modify documents within a child database, but you don’t want to go to the trouble of creating a child database-specific key. If you just need to create/delete child databases, you would use an admin key for the parent database.
Per-customer databases are a common use of Fauna’s multi-tenant capability. You can generate keys for a child database and hand them to a team/customer that should work solely in the child database. BYOK is a great term for that!
,
.
.