Simulating DDL Triggers via External Server Plugin

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Database systems often lack hardcoded support for triggers that activate in response to Data Definition Language (DDL) operations, limiting their ability to simulate triggers for events like schema modifications, which are essential for replication and other scenarios.

Innovation Solution

A system comprising a Database Server and an External Trigger Server, where a plugin detects specific queries and sends notifications to the External Trigger Server to simulate triggers, enabling support for DDL operations by external processes, allowing for replication of database changes across systems.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If database systems use hardcoded triggers for DML operations, then trigger functionality is reliable and integrated, but the system cannot support triggers for DDL operations or other custom events

Engineering Contradiction:
Improvetrigger event type supportVSAvoidsystem architecture
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system separates trigger functionality into two independent components: the database server handles core DML operations with native trigger support, while an external trigger server handles DDL operations and other custom events. This segmentation allows each component to specialize in specific event types without requiring the database server to support all possible trigger scenarios natively.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

An external trigger server acts as an intermediary between the database server and trigger execution. The external server receives notifications about DDL operations and other events, processes them through defined triggers, and executes appropriate actions. This mediator approach enables trigger functionality for events that the database server does not natively support.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If database systems provide native trigger support, then trigger execution is fast and integrated, but external processes cannot handle unsupported trigger events

Engineering Contradiction:
Improvetrigger executionVSAvoidevent type coverage
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The external trigger server provides universal trigger handling capability across multiple event types including DDL operations, DML operations, and custom events. By implementing a general-purpose trigger processing system that can handle various event types through a unified interface, the solution achieves multi-functionality without requiring separate native support for each event type in the database server.

Inventive Principle:
Principle #6Universality (Multi-functionality)

3Adaptability or versatility

If the system extends trigger support to DDL operations, then functionality is enhanced, but the database system's hardcoded limitations are violated

Engineering Contradiction:
ImproveDDL trigger supportVSAvoidimplementation approach
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The external trigger server serves as an intermediary that receives notifications of DDL operations from the database server and processes them through user-defined triggers. This approach extends trigger functionality to DDL operations without modifying the database server's core architecture or violating its hardcoded limitations, as the extension occurs in the external layer.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS11797495B2Simulating data definition triggers in a database system
Publication Date: 2023.10.24 ORACLE INT CORP
  • US11797495B2 patent drawing
  • US11797495B2 patent drawing
  • US11797495B2 patent drawing

AI summary

Techniques are described herein for simulating triggers in a database. A database server receives a query that targets a database managed by the database server. The database server is registered with a plugin that determines whether the query is a particular type of query. If so, plugin sends a message to an external process that includes features of the query. The database server can also execute the query regardless of whether the particular type of query is detected.