Importing Data

This guide details importing data using CSV files, including fast data imports. Data to be imported needs to be in JSON format; it is an array of user data and an array of records data:

General Information

Here are a couple of details that you need to know before importing data:

• Deploy your Database Tables before importing.
• The system will change the fields and keep existing relations when importing data. If your relations are defined in properties, you must first describe them in Database Table files.
• If you test your imports and need to clean Instance data, use the command. Note that this command will work only on staging Instances.
• When you run import twice, it will try to match previously imported data without removing existing changes. Example:
  1. You have a record with properties: ,
  2. First import adds new with JSON:
  3. User sets attributes of , now has the following properties:
  4. The second import with the same file changes the object to:
• Import will only do basic validations, such as the existence of properties and type validation. It doesn't check any of the validations defined on forms.

Data Import with the command line interface (CLI)

With insites-cli data, you can export/import Instance data (information entered by the users).

The Insites CLI tool provides the command for uploading and importing data from a JSON file or ZIP archive with CSV files. It accepts one option:

--path (short: -p): A path to a JSON or ZIP file to be imported

Under the hood, the CLI uses the GraphQL import API described in the next section. However, using the CLI provides some significant benefits:

• Uploading files from the disk
• Leveraging the CLI's authentication mechanism (i.e. you don't need to send your authentication token manually).

Input format

The required data format is a JSON file with users and records keys that have an array of maps. Each collection must be in the same format as a corresponding GraphQL mutation. Under the hood, import is just a set of mutations: and . When importing data using the CLI, the file should contain data in a format that matches the following structure:

Example

Example data import file

To import the data from a file, run the following command in the terminal:

Data Import with GraphQL mutations

It is possible to import data using GraphQL mutations. This method gives you more flexibility and even allows you to create your import tool as a website feature. Please remember to handle authentication properly.

There are two primary mutations for importing: and . You can create a page that will import sent data.

app/graphql/import_data.graphql

app/views/pages/import_data.json.liquid

Data Import with raw import API

Our CLI uses the HTTP API to import a data file. You can use it in your own tool.
Please note that you need to provide your authentication token in the HTTP Authorisation header of the request.

Data import using CSV files

It is possible to import data using CSV files — this is the most straightforward and performant way of data import.

CSV data format

Inside the ZIP archive, there should be CSV files with data to be imported. For example:

Some reminders:

• Before import, your Tables need to be deployed.
• CSV files only support comma-separated values. If in doubt, it might be a good idea to use a linter like CSVlint to check the file.
• A well-formatted file has a header with names of columns available for the given type and one or more rows of data.

Example file for Records

This file will import Records matching the Table for "todo". If you notice, there's a typo in the object with id=3. To fix it, you can edit the file like this:

And now, importing will update the data of matching rows. Even if you add new rows, the system will only add these new rows; the system will not delete existing rows. Additionally, not all columns are required, so the code in the example below will work as well:

Example file for Users

It is important to note that will only work if you import data previously exported from our system through other means. So setting passwords this way will not work: they will be saved, but the system will not accept them when checking through the application code. It would be unsafe to set passwords this way, so it's better to use a random value here and require users to change their passwords after migration.

Example file for UserProfiles