Skip to main content

Wait Column

Waits until a new column is added to a specified table. This node blocks execution until a schema change is detected.

Common Properties​

  • Name - The custom name of the node.
  • Color - The custom color of the node.
  • Delay Before (sec) - Waits in seconds before executing the node.
  • Delay After (sec) - Waits in seconds after executing node.
  • Continue On Error - Automation will continue regardless of any error. The default value is false.
info

If the ContinueOnError property is true, no error is caught when the project is executed, even if a Catch node is used.

Inputs​

  • Connection Id - The unique identifier of the database connection to use (optional if credentials provided directly).
  • Table Name - The name of the table to monitor for new columns. Can include schema name (e.g., schema.table).

Options​

  • Poll Time (s) - Time interval in seconds between checks for new columns. Default: 1.0 second.
  • Credentials - MySQL database credentials (optional). Use this if you want to wait without a Connect node.
  • Parameters - Additional connection string parameters (optional). Only used when credentials are provided.

Output​

  • None - The node completes when a new column is detected in the table.

How It Works​

The Wait Column node monitors a table's schema for new columns. When executed, the node:

  1. Retrieves the database connection (either from connection ID or creates new connection from credentials)
  2. Validates the table name is not empty
  3. Constructs a query to count columns in the table using INFORMATION_SCHEMA
  4. On first check, records the current column count (baseline)
  5. Polls the table schema at the specified interval
  6. Compares the current column count with the baseline
  7. Continues execution when the count increases (new column added)
  8. Blocks the flow until the condition is met

Requirements​

  • Either: A valid connection ID from Connect node OR valid database credentials
  • Valid table name that exists in the database
  • Database user must have SELECT permission on INFORMATION_SCHEMA.COLUMNS
  • Active database connection during the wait period

Error Handling​

The node will return specific errors in the following cases:

  • ErrInvalidArg - Table name is empty
  • ErrNotFound - Connection ID not found

Table Name Format​

Simple Table Name​

Table Name: users

Monitors the "users" table in the current database.

Table with Schema​

Table Name: mydb.users

Monitors the "users" table in the "mydb" schema specifically.

Usage Examples​

Wait for Schema Migration​

Connect
  ↓
Wait Column
  - Table Name: users
  - Poll Time: 2.0
  ↓
Query (verify new column exists)
  - SHOW COLUMNS FROM users LIKE 'new_column'
  ↓
Non Query (populate new column)
  - UPDATE users SET new_column = default_value
  ↓
Disconnect

Monitor External Schema Changes​

Connect
  ↓
Loop (continuous monitoring)
    ↓
    Wait Column
      - Table Name: products
      - Poll Time: 5.0
      ↓
    Query (get column details)
      - SELECT COLUMN_NAME, DATA_TYPE
        FROM INFORMATION_SCHEMA.COLUMNS
        WHERE TABLE_NAME = 'products'
        ORDER BY ORDINAL_POSITION DESC
        LIMIT 1
      ↓
    Log schema change
      ↓
    Send notification

Coordinate with Migration Tool​

External Migration Tool runs ALTER TABLE
  ↓
Wait Column (detect schema change)
  - Table Name: customers
  - Poll Time: 1.0
  ↓
Query (verify column properties)
  ↓
Non Query (update data for new column)
  ↓
Send completion notification

Common Use Cases​

  1. Schema Migration Coordination - Wait for database migrations to complete
  2. Multi-System Synchronization - Coordinate schema changes across systems
  3. External Tool Integration - React to schema changes made by external tools
  4. Deployment Automation - Ensure schema changes complete before deploying application
  5. Schema Monitoring - Monitor for unexpected schema modifications
  6. Development Workflows - Coordinate between development and automation scripts
  7. Data Pipeline - Wait for schema preparation before data import

Polling Behavior​

Initial Baseline​

On the first check:

  1. Counts current columns in the table
  2. Stores the count as the baseline
  3. Continues polling

Subsequent Checks​

On each poll:

  1. Counts current columns in the table
  2. Compares with baseline
  3. If count increased → new column added → node completes
  4. If count same or decreased → continues polling
  5. Updates baseline to current count

Poll Interval​

The Poll Time option controls check frequency:

  • Lower values (1s) - More responsive but higher database load
  • Higher values (5s) - Less database load but slower to detect

Tips for Effective Use​

  • Poll Time Balance - Balance responsiveness vs database load
  • Schema Qualification - Include schema name to avoid ambiguity
  • Timeout Strategy - Implement timeout for cases where column might not be added
  • Connection Stability - Ensure connection stays alive during wait
  • Migration Coordination - Use to coordinate with database migration tools
  • Testing - Test with SHOW COLUMNS FROM table to understand current state
  • Monitoring - Log when waiting starts and ends for debugging

Best Practices​

With Timeout​

Connect
  ↓
Parallel
  ├─ Wait Column (wait for schema change)
  │   - Table Name: products
  │   - Poll Time: 2.0
  └─ Delay (timeout after 5 minutes)
      - Delay: 300 seconds
  ↓
If (Wait Column completed first)
  └─ Proceed with data migration
Else
  └─ Log timeout and alert
  ↓
Disconnect

Verify Column Properties​

Wait Column (detect new column)
  - Table Name: users
  ↓
Query (get column details)
  - SELECT COLUMN_NAME, DATA_TYPE, IS_NULLABLE, COLUMN_DEFAULT
    FROM INFORMATION_SCHEMA.COLUMNS
    WHERE TABLE_NAME = 'users'
    ORDER BY ORDINAL_POSITION DESC
    LIMIT 1
  ↓
JavaScript (verify column properties match expectations)
  ↓
If (properties correct)
  └─ Continue processing
Else
  └─ Alert schema mismatch

Deployment Coordination​

Deploy Application (new version expecting new column)
  ↓
Connect
  ↓
Parallel
  ├─ Run Migration Script (adds column)
  └─ Wait Column (wait for column)
      - Table Name: mydb.users
      - Poll Time: 1.0
  ↓
When both complete:
  ↓
Restart Application Services
  ↓
Disconnect

Schema Evolution Tracking​

Connect
  ↓
Loop (continuous monitoring)
    ↓
    Wait Column
      - Table Name: {{monitoredTable}}
      - Poll Time: 10.0
      ↓
    Query (get new column details)
      ↓
    Insert (log schema change)
      - INSERT INTO schema_changes_log
        (table_name, column_name, change_type, detected_at)
        VALUES ({{table}}, {{column}}, 'COLUMN_ADDED', NOW())
      ↓
    Send notification to team

Performance Considerations​

  • Poll Frequency - More frequent polling increases database load (but INFORMATION_SCHEMA queries are generally fast)
  • Schema Complexity - Tables with many columns might have slightly slower queries
  • Information Schema - INFORMATION_SCHEMA queries are read-only and cached
  • Connection Overhead - Keep connection open to avoid reconnection overhead

Common Errors and Solutions​

Table Name Cannot Be Empty​

Error: ErrInvalidArg: Table name cannot be empty

Solutions:

  • Provide a valid table name
  • Ensure the variable containing the table name has a value
  • Include schema name if needed (e.g., mydb.users)

Connection Not Found​

Error: ErrNotFound: Connection not found

Solutions:

  • Ensure Connect node runs before Wait Column
  • Verify connection ID is correct
  • Or use Credentials option to connect directly

Timeout or Infinite Wait​

Issue: Node waits indefinitely if column is never added

Solutions:

  • Implement timeout using Parallel node with Delay
  • Add maximum wait time logic
  • Verify migration script actually runs
  • Check migration script for errors

Table Doesn't Exist​

Issue: Monitoring a table that doesn't exist

Solutions:

  • Verify table name is correct
  • Ensure table exists in the database
  • Check schema name is included if needed
  • Use SHOW TABLES LIKE 'tablename' to verify

Advanced Examples​

Get New Column Details​

Wait Column (detect new column)
  - Table Name: products
  ↓
Query (get all columns ordered by position)
  - SELECT COLUMN_NAME, DATA_TYPE, COLUMN_DEFAULT
    FROM INFORMATION_SCHEMA.COLUMNS
    WHERE TABLE_NAME = 'products'
    ORDER BY ORDINAL_POSITION DESC
  ↓
JavaScript (first column is the new one)
const newColumn = $item.result.rows[0];
console.log('New column:', newColumn.COLUMN_NAME);
  ↓
Process based on new column

Multi-Table Schema Monitoring​

Parallel (monitor multiple tables)
  ├─ Wait Column
  │   - Table Name: users
  ├─ Wait Column
  │   - Table Name: products
  └─ Wait Column
      - Table Name: orders
  ↓
Process whichever triggers first

Migration Verification​

Non Query (run ALTER TABLE ADD COLUMN)
  - ALTER TABLE users
    ADD COLUMN email_verified BOOLEAN DEFAULT FALSE
  ↓
Wait Column (verify column was added)
  - Table Name: users
  - Poll Time: 1.0
  ↓
Query (verify column exists)
  - SELECT COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS
    WHERE TABLE_NAME = 'users'
      AND COLUMN_NAME = 'email_verified'
  ↓
If (column exists)
  └─ Migration successful
Else
  └─ Migration failed

Continuous Schema Auditing​

Connect
  ↓
Loop (infinite)
    ↓
    Wait Column
      - Table Name: {{auditTable}}
      - Poll Time: 30.0
      ↓
    Query (get table schema)
      - SELECT * FROM INFORMATION_SCHEMA.COLUMNS
        WHERE TABLE_NAME = {{auditTable}}
      ↓
    JavaScript (compare with expected schema)
      ↓
    If (unauthorized change detected)
      ├─ Log security event
      └─ Send alert to DBA team
      ↓
    Update schema baseline

Database Upgrade Workflow​

Backup Database (safety backup)
  ↓
Connect
  ↓
Execute Migration Script (external process)
  ↓
Wait Column (wait for schema change)
  - Table Name: version_table
  - Poll Time: 2.0
  ↓
Query (verify database version)
  - SELECT version FROM version_table
    ORDER BY applied_at DESC
    LIMIT 1
  ↓
JavaScript (verify version matches expected)
  ↓
If (version correct)
  ├─ Update application configuration
  └─ Restart services
Else
  └─ Restore from backup
  ↓
Disconnect

Polling Query​

The node uses this query internally:

Without Schema​

SELECT COUNT(*)
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME LIKE 'tablename'

With Schema​

SELECT COUNT(*)
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'schema'
  AND TABLE_NAME LIKE 'tablename'

Schema Change Detection​

What Triggers the Node​

  • Adding a column - ALTER TABLE ADD COLUMN
  • Multiple columns added - Any increase in column count

What Doesn't Trigger​

  • Removing a column - Column count decreases (not detected)
  • Modifying a column - MODIFY COLUMN (count stays same)
  • Renaming a column - RENAME COLUMN (count stays same)
  • Changing column type - ALTER COLUMN (count stays same)

Alternatives​

If Wait Column doesn't fit your use case:

Polling Loop for Specific Column​

Loop
    ↓
    Query (check if column exists)
      - SELECT COUNT(*) FROM INFORMATION_SCHEMA.COLUMNS
        WHERE TABLE_NAME = 'tablename'
          AND COLUMN_NAME = 'specific_column'
      ↓
    If (count > 0)
      └─ Break Loop (column exists)
    Else
      └─ Delay and continue

Event-Driven Approach​

If you control the schema changes:

  • Trigger flow after ALTER TABLE
  • Use HTTP trigger from migration script
  • Use message queue notification

Database Triggers​

MySQL doesn't support DDL triggers, but you could:

  • Log schema changes to a table
  • Use Wait Row to monitor that table

See Also​