Table modes
Each table can be assigned a table mode. The table mode determines at a high level how the table is populated in the destination database.
Both Database View and Table View allow you to view and update the selected table mode for a table.
This is the default table mode for new tables.
In this mode, Tonic copies over all of the rows to the destination database.
For columns that have the generator set to Passthrough, Tonic copies the original source data to the destination database.
For columns that are assigned a generator other than Passthrough, Tonic uses the generator to replace the column data in the destination database.
In this mode, Tonic generates an arbitrary number of new rows, as specified by the user, using the generators that are assigned to the table columns.
You can use linking and partitioning to create complex relationships between columns.
Tonic generates primary and foreign keys that reflect the distribution (1:1 or 1:many) between the tables in the source database.
This mode drops all data for the table in the destination database.
For data connectors other than Spark-based data connectors, the table schema and any constraints associated with the table are included in the destination database.
For Spark-based data connectors (Amazon EMR, Databricks, Spark SDK, Spark with Livy), the table is ignored completely.
Any existing data in the destination database is removed. For example, if you change the table mode to Truncate after an initial data generation, the next data generation clears the table data. For Spark-based data connectors, the table is removed.
If you assign Truncate mode to a table that has a foreign key constraint, it fails during data generation. If this is a requirement, contact [email protected] for assistance.
This mode preserves the data in the destination database for this table. It does not add or update any records.
This feature is primarily used for very large tables that don't need to be de-identified during subsequent runs after the data exists in the destination database.
When you assign Preserve Destination mode to a table, Tonic locks the generator configuration for the table columns.
The destination database must have the same schema as the source database.
Incremental mode only processes the changes that occurred to the source table since the most recent data generation or other changes in the destination. This can greatly reduce generation time for large tables that don't have a lot of changes.
For Incremental mode to work, the following conditions must be satisfied:
- The table must exist in the destination database. Either Tonic created the table during data generation, or the table was created and populated in some other way.
- A reliable updated date column must be present. When you select Incremental mode for a table, Tonic prompts you to select the updated date column to use.
- The table must have a primary key.
To maximize performance, we recommend that you have an index on the date updated field.
For tables that use Incremental mode, Tonic checks the source database for records that have an updated date that that is greater than the maximum date in that column in the destination database.
To ensure accurate incremental processing of records, we recommend that you do not directly modify the destination database. A direct modification might cause the maximum updated date in the destination database to be after the date of the last data generation. This could prevent records from being identified for incremental processing.
For the identified records, Tonic checks for primary key matches between the source and destination databases, then does one of the following:
- If the primary key value exists in the destination database, then Tonic overwrites the record in the destination database.
- If the primary key value does not exist in the destination database, then Tonic adds a new record to the destination database.
This mode currently only updates and adds records. Rows that are deleted from the source database remain in the destination database.
Incremental mode is currently supported on PostgreSQL, MySQL, and SQL Server. If you want to use this table mode with another database type, contact [email protected].
These options are only available for workspaces that use the following data connectors:
The Amazon EMR, Databricks, and Spark with Livy data connectors do not support subsetting.
However, for tables that use De-identify mode, you can provide a filter. The filter identifies the rows from the source database to process and include in the destination database.
To add a filter, in the Partition Filter text area, provide the where clause for the filter.
Partition Filter option for a table
For Databricks workspaces where the source database uses Delta files, the filter where clause can only refer to columns that have partitions.
For Amazon EMR and Spark with Livy, the filter where clause can refer to columns without partitions. However, the performance is better when the referenced columns have partitions.
On the workspace configuration, the Enable partition filter validation toggle determines whether Tonic validates the where clause when you create it. By default, the toggle is in the on position, and the where clause is validated.
For Amazon EMR, Databricks, and Spark with Livy workspaces, you can use the Repartition or Coalesce option to indicate a number of partitions to generate.
By default, the destination database uses the same partitioning as the source database. The partition option is set to Neither.
The Repartition option allows you to provide a specific number of partitions to generate. To use the Repartition option:
- 1.Click Repartition.
- 2.In the field, enter the number of partitions.
The Coalesce option allows you to provide a maximum number of partitions to generate. If the source data has fewer partitions than the number you specify, then Tonic only generates that number. The Coalesce option should be more efficient than the Repartition option.
To use the Coalesce option:
- 1.Click Coalesce.
- 2.In the field, enter the number of partitions.