Ability to migrate multiple namespaces in a database

[RonB]

I am testing with this repo and first impression is very good. I have it working as a remote package in my monorepo. That repo has different apps which are deployed in Docker containers. When deploying a version of the app the migration should run. That is done in the Dockerfile just before starting the app. The surrealdb database I use is configured with a root namespace where all customers have access, and per customer a namespace in the same database is created to create a multi-tenant setup. The root has other tables than the customer namespace.

This means 2 issues:

1. Multiple namespaces
2. Different migration querys per namespace

This means i have 2 kinds of migration .surql files. One for the root and one for all customer namespaces. A solution could be to update the naming convention of like so:

0001.{namespace}.{do|undo}.{description}.surql and set the name of the namespace accordingly and check for that in the index.js.

{namespace} could have a value like the namespace name (root) or a wildcard (.

We would need to check the namespaces available in the database and apply the migration to the specific namespace that has its own migrations and introspections tables.

Another approach would be to update the config.yaml where we can configure different namespaces and possibly assign some surql migration files to apply to those namespaces.

Please let me know how you feel about this change.

Regards Ronald

[daviddyess]

I think it's an excellent capability to have. I am wondering which path would lead to fewer mitigations or restrictions down the road. Would it be better if we could have namespaced folders under ./migrations? Or maybe namespaced versions, like {namespace}.0001.{do|undo}.{description}.surql? It could be configurable to work either way? I think my only concern is keeping the migrations table clean and versions linear, but namespaced versions would mean each namespace could have linear versions and not be as connected to other namespaces in migration history.

Unfortunately I'm still new to SurrealDB, so there is still much for me to learn about how it can/is used and how to build the best migration tool possible.

I'm definitely willing to implement this or accept any PRs for it.

[RonB]

If namespaces are used for multi-tenancy then they will usually have the same model/entities and thus the same version. Your concern is therefore justified. There are multiple architectures with not only multiple namespaces but also might use multiple databases per project, use schema-definition tools etc.

There is another project that is written in rust and has some attention surrealdb-migrations. It uses a different approach where not only migrations are stored in surql files but the schema definitions and event definitions as well. I have posted a general question on Discord in the tools section to check how the Surrealdb community looks at migrations in general. Maybe you can also have a look at the previous mentioned project and also check into Discord to see if we can get some attention for your project as well.

[daviddyess]

Thank you, that is helpful. So I'm thinking the starting point is determining the best approach for configuring Surrealigrate to know what to do for each database and how to simplify the administrative needs to maintain that. I only have my phone to browse with at the moment but I'll look into that rust project and see what their approach is this evening.