This new command will open avenues to ease migrations from one database to another. This function will have this format CopyDatabase(from, to), similar to the MoveDatabase function.
The function should create a deep clone of the original database
Use cases:
Migrating data across development environments
Alpha, Beta testing with test users with the hope to migrate their data across various testing stages (helpful in a multitenant app)
Update: The new function should take a third optional parameter (object) which provides control over what data types should be copied in this example: CopyDatabase(from, to, [{ collections: true, indexes: false, functions: true}]).
If the optional third parameter is not specified, the default is to copy all user-created collections, indexes, functions, and, roles. When the third optional parameter is specified it should overwrite the default.
I’m curious to hear your thoughts about what should happen with existing Keys, Tokens, and AccessProviders? These documents are involved in authentication and authorizations, and are connected to a specific database.
For example, if you have an admin key for database A, and then you CopyDatabase(A, B), when someone uses the admin key, which database should that person be connected to?
The goal is to copy the user created Collections. Functions, Indexes and not the system Keys, Tokens, etc. The CopyDatabase function can take a third optional parameter (object) for cases where additional system elements which make sense for the migration use case. For your example, I cannot see a use case currently for migrating existing Keys since the Key will have to be unique across databases,
Hey @Samuel_Danquah , thanks for your suggestion. To clarify, does that also include the documents in collections? I’m currently assuming it does. This would probably not be a function that is transactional given the massive data that could potentially be copied like that. I might be wrong but I’m assuming therefore that it would most likely be a tool rather than an FQL extension.
However, if it’s only collections/indexes etc… I see value in making databases from a template database on the fly. Especially in the scenario where users are using multiple databases for multi-tenancy.
It would be problematic to migrate potential large document datasets in Collections. Migrating the template (just the Collections, Indexes etc) is more pragmatic. If there is the need to populate the new database with some seed data, they can resort to running a script. This will prevent accidental high transaction costs if there are lots of existing data in the case of someone harmlessly trying out the CopyDatabase function