How Trinium works
Test runs
The amber Test button runs your pipeline on a sample, so you can see what every node does without touching a real destination.
What a Test run does
- It runs a sample. At most 50 rows pass through each node.
- It uses Staging. Every connection is read through its Staging side.
- It writes nothing outside Trinium. Database, warehouse, API and email outputs take their rows and write none, and file outputs are not delivered. A Send Email node renders every message and sends none.
- It consumes nothing. Source files are never moved, deleted or marked as read by a Test run.
- Sources really read. A source's query runs, and so does its pre-SQL; only the amount is limited. A cloud folder downloads a sample: the first file, then more until there are 50 files or 64 MB.
Run to here on a node runs only the part of the pipeline that feeds it. You can also Test a saved version, which runs that version's own nodes and parameters.
What you see
The dock under the canvas shows up to 50 rows from each output of each node, its columns and their types, and its messages. A node's columns from its last Test run stay available to the builder.
Limits
- Each server runs one Test run beside whatever production run is going, in a small slice of memory of its own, so a Test never waits behind a long load and never slows it down.
- A Test run stops after 15 minutes.
- Finished Test runs are deleted after 30 days, because their previews hold real rows. The history of Live runs is kept.
A Test run is not a smaller production run. To check a full load, deploy to Staging and run it there: see Versions, Staging and Production.