In this article
You can use the Redshift Execute Snap to execute arbitrary SQL queries. It executes DML (SELECT, INSERT, UPDATE, DELETE) type statements. This Snap works best with single queries.
The Redshift Execute Snap is a Write-type Snap that writes the results of the executed SQL queries.
Supported Redshift database environment and Redshift database account with valid access control.
Works in Ultra Pipelines.
If you use the PostgreSQL driver ( If you use the PostgreSQL driver ( |
When the SQL statement property is an expression, the pipeline parameters are shown in the suggest, but not the input schema.
Multiple queries might not work, because the underlying JDBC driver does not support multiple queries. We recommend you to use the Redshift - Multi Execute Snap for running multiple queries.
Type | Format | Number of Views | Examples of Upstream and Downstream Snaps | Description |
|---|---|---|---|---|
Input | Document |
|
| A Snap that can contain data that is to be used with the JSON paths defined in the SQL, if any, or to be passed through. If the input view is defined, then the where clause substitutes incoming values for a specific query. |
Output | Document
|
|
| A document with the result set output, if any, and update count as return status from the Redshift SQL. The Snap output all records of a batch (as configured in your account settings) to the error view if the write fails during batch processing. If an output view is available and an update/insert/merge/delete statement was executed, then the original document that was used to create the statement will be output with the status of the executed statement. |
Error | Error handling is a generic way to handle errors without losing data or failing the Snap execution. You can handle the errors that the Snap might encounter when running the Pipeline by choosing one of the following options from the When errors occur list under the Views tab:
Learn more about Error handling in Pipelines. | |||
|
Field Name | Field Type | Description | ||
|---|---|---|---|---|
Label*
| String | Specify the name for the Snap. | ||
SQL statement*
| String/Expression | Specify the SQL statement to execute on the server.
| ||
Query type
Default Value: Auto | Dropdown list/Expression | Select the type of query for your SQL statement (Read or Write). When Auto is selected, the Snap tries to determine the query type automatically. | ||
Pass through
| Checkbox | Select this checkbox to pass the input document through to the output view under the key 'original'. This property applies only to the Execute Snaps with SELECT statement. | ||
Ignore empty result
| Checkbox | Select this checkbox to ignore empty result; no document will be written to the output view when a SELECT operation does not produce any result. | ||
Number of retries Default Value: 0 | Integer/Expression | Specify the maximum number of attempts to be made to receive a response. The request is terminated if the attempts do not result in a response. Ensure that the local drive has sufficient free disk space to store the temporary local file. Ensure that the local drive has sufficient free disk space to store the temporary local file. | ||
Retry interval (seconds) Default Value: 1 | Specify the time interval between two successive retry requests. A retry happens only when the previous attempt resulted in an exception. | |||
Auto commit
| Dropdown list | Select one of the following options:
Behavior of DML Queries in the Execute Snap when auto-commit is false
Behavior of DML Queries in the Execute Snap when auto-commit is false
| ||
Snap Execution
| Dropdown list | Select one of the three modes in which the Snap executes. Available options are:
|
Error | Reason | Resolution |
|---|---|---|
| This issue occurs due to incompatibilities with the recent upgrade in the Postgres JDBC drivers. | Download the latest 4.1 Amazon Redshift driver here and use this driver in your Redshift Account configuration and retry running the Pipeline. |
Scenario 1: Executing SQL statements without expressions When you deselect the expression toggle of the SQL statement field:
.png?version=1&modificationDate=1489839414372&cacheVersion=1&api=v2 "SnapLogic Documentation > Redshift - Execute > SQL statement without expressions (4).png") The JSON path is allowed only in the WHERE clause. If the SQL statement starts with SELECT (case-insensitive), the Snap regards it as a select-type query and executes once per input document. If not, it regards it as write-type query and executes in batch mode. Scenario 2: Executing SQL queries with expressions When you select the expression toggle of the SQL statement field:
.png?version=1&modificationDate=1489839413116&cacheVersion=1&api=v2 "SnapLogic Documentation > Redshift - Execute > SQL statement with expressions (4).png") Note: Table and column names must not be provided as bind parameters. Only values can be provided as bind parameters. |
The non-expression form uses bind parameters, so it is much faster than executing N arbitrary SQL expressions.
Using expressions that join strings together to create SQL queries or conditions has a potential SQL injection risk and hence unsafe. Ensure that you understand all implications and risks involved before using concatenation of strings with '=' Expression enabled.
The '$' sign and identifier characters, such as double quotes (“), single quotes ('), or back quotes (`), are reserved characters and should not be used in comments or for purposes other than their originally intended purpose.
Any relational database (RDBMS) treats single quotes (') as special symbols. So, single quotes in the data or values passed through a DML query may cause the Snap to fail when the query is executed. Ensure that you pass two consecutive single quotes in place of one within these values to escape the single quote through these queries. For example:
If String | To pass this value | Use |
Has no single quotes | Schaum Series | 'Schaum Series' |
Contains single quotes | O'Reilly's Publication | ' |
Be cautious when running your queries, because you can drop your database and lock tables while executing SQL statements.
Running multiple queries might not work with the Redshift - Execute Snap. If you need to run multiple queries, we recommend you to use the Redshift -Multi Execute Snap.
This Snap enables the following ETL operations/flows:
Extract data from an existing Redshift Table.
Transform any input document SnapLogic types to Redshift JDBC types for any input and transform any output document Redshift JDBC types to SnapLogic types for output.
Load data in the Redshift table.
The SQL (to be executed) is passed to Redshift. Here’s the detailed data flow:
The Snaps collects the user account information, and the SQL statement (after any expression evaluation), and any JDBC jars defined in the Redshift database account. JDBC jars defined in the Redshift database account are at customer discretion and should be Redshift approved/supported.
Valid JSON paths that are defined in the WHERE clause for queries/statements will be substituted with values from an incoming document as a prepared statement. The substituted values will be transformed from the SnapLogic type value to the appropriated JDBC type values based on the database's column type. If there are no JSON paths then a JDBC query will be utilized instead of a prepared statement.
Successful execution may create a result set. The result set columns will be transformed from the JDBC type value to the SnapLogic type value.
Data errors may occur, therefore an error view should be created to handle these conditions. If the batch has a data error the error data will be written to the error view and the rest of the batch will not be processed. However, a batch data error will not stop subsequent batches from executing.
Select SQLs will not use auto-commit. For non-select SQL, commit happens at successful batch completion when the database account has Auto commit enabled. If the database account does not have Auto commit enabled, commit happens at end of the successful Snap run. Therefore the Auto commit the setting must be configured to be processed in the desired way. For example, If a downstream Snap needs to see the data in the database, auto-commit should be enabled.
The database account uses a shared connection pool for efficiency and to prevent opening too many connections to a database. It is possible that another Snap with the same database account settings may be reusing the same connection as the Redshift Execute. To avoid reusing another Snap's connection for the purpose of isolating DML operations or debugging connection operations, use a different database account having different settings - this will cause the database connection to be unique to the Redshift Execute Snap.
The use case requirement for this basic example is that we want to leverage the database query engine to provide uniqueness, a different output column, and a literal output value that the Redshift Select Snap cannot perform by itself. This example demonstrates how you can leverage other database query engine capabilities (functions, joins, and so on) and create more complex results than just getting filtered data out of a table.
The key configuration of the Snap lies in how you pass the SQL statements.
Without Expression: Directly passing the required SQL statement in the Redshift Execute Snap.
JSON path example below, a statement is prepared and parameter values binded (from matching input document field) and executed using database account batch configuration of batch size 2. The JSON Generator preview shows the input values flowing into the Redshift Execute. The image at the right shows two output records. Note that only the input document with $name = "Danila" found a matching result in Redshift. The input document with $name = "Prasanna" was executed but returned no rows because the data was case sensitive and therefore did not match the database data value of "prassanna" . Because the Pass through checkbox was select and the original document is preserved in the output view.
The error view was enabled above so that processing can continue to end. Below is the error in the error output view.
With Expressions
An input document field named $tracked is used instead of hard coding "true" from the basic example above. An example value of $tracked is "'true'".
Pipeline Parameter: Pipeline parameter set to pass the required SQL Statement to the Redshift Execute Snap.
Same expression example, this time using pipeline parameter instead of an input document field reference.
This example demonstrates how to use the Redshift Execute to insert precision numbers into a Redshift table using JSON Path expressions which will have the Redshift Execute create prepared statements, bind the input document field references, and execute using batching where the Redshift database account is configured with a batch size of 2. Below is a screenshot showing the more complex pipeline, the Redshift Execute configuration, and the inputs coming into the Redshift Execute.
The following image shows the error output view data:
Here is the regular output view data:
This example pipeline demonstrates how to call a stored procedure using the Redshift Execute Snap.
Create a store procedure sp_inout_proc as shown below. This stored procedure contains three values: a, b, and c.
On validating the Pipeline, the stored procedure is executed, and you can view only the status, message, and message description.
Next, we configure another Redshift Execute Snap to call the same sp_inout_proc stored procedure with these three values. 
After validating the Pipeline, the Snap gets the values from the procedure and the output of the stored procedure is displayed as follows:
): Indicates a list that is dynamically populated based on the configuration.