Easier way to copy data from deployment environments?

Is there an easier way to copy data from, for example, a testing deployment environment to staging deployment environment? I've found it to be tedious to export a csv from testing and then importing it into staging. Is there a way to do this through CloudCode?

Yes, there is an option to do this via CloudCode. One can write a script that copies data from one environment and creates, updates or deletes data in another.

In the official documentation, the Multiple Database Access section describes how one can configure multiple references, each pointing to their own DB environment.

Warning

When executing reads/writes his will throw errors if there are differences between the data models in the different environments.

Example

export async function run() {

    // Configure another environment
    const StagingDB = CloudCode.createDB('https://run-us.journeyapps.com/', 'myinstanceid', {token: 'mytoken'});

    // DB will still be the current environment DB
    var user = await DB.user.first('name = ?', 'Mark');
    var copyOf = StagingDB.user.create({
        name: user.name
    });

    await copyOf.save()

}
3 Likes

@MichaelBarnes How do you connect a specify data model to a specific environment?

@AlexValdez Could you elaborate on what you mean by a specific data model?

@MichaelBarnes I was wondering if it was possible to specify different data models for different environments. From my understanding, it sounds like that’s not possible. Unless,Git integration is implemented. Then, it’s possible via branching.

@AlexValdez Without knowing the specifics of your use case, this does sound correct. The answer above is a mechanism to perform the migration of data, manually, from one environment to another. i.e. You’ll need to specify the models and values that need to be copied over. Hope this answers your question.

@MichaelBarnes It makes it slightly tough to test environments if I’m trying to test a new model. For instance, if I made an update to the data model by adding a model (let’s assume I’m not using Git integration) to test, then I have to manually remove that model if I don’t want it in a different environment. It seems like it could be useful to have the data model separate from the code base. However, it does answer my question. Thanks, Michael!

@AlexValdez , the reason the data model is not separate from the rest of the application is because the data model is so tightly coupled with everything else. If the two were separate then in our opinion you would run into more issues as you would need to manually ensure that the rest of your codebase is not referencing models or fields that are not specified in your data model and this could lead you to being allowed to deploy code that isn’t actually executable, ie view logic that is based on models or fields that don’t exist.

@TielmanleRoux Yeah that makes perfect sense. It’s a use case that could be applicable to our team right now but maybe not in the future. And I know sticking to a specific pattern and more reliable pattern can absolutely be a great thing. Thanks for the info!

@AlexValdez No worries. That said, your general use case of wanting to test several features or changes in parallel is definitely not uncommon, in fact it is really really common, and is exactly what the Github integration solves for. I can definitely recommend looking into that, if you have time. Also note, our new IDE will eventually support this type of thing by default, but you may still want your own Github account and integration as that will give you full control