DBMS Test Pipelining via Runtime Data Store

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Prior art diagnostics software lacks the ability to pipeline data between tests written in different programming languages, specifically between Java and PL/SQL, requiring users to write tests in Java for data transfer, which is cumbersome and requires Java knowledge.

Innovation Solution

Implementing a method that allows for data pipelining between tests written in DBMS procedural languages like PL/SQL by creating a container test with specific procedures and using pseudo-objects to interface with Java, enabling data transfer across different language tests.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If users write test scripts in Java to enable data pipelining between tests, then data transfer capability is improved, but ease of operation deteriorates because users require Java programming knowledge

Engineering Contradiction:

Improvedata transfer capabilityVSAvoidease of writing tests

Core Design Contradiction:

Adaptability or versatilityVSEase of operation

Solution Approach 1:

The patent introduces a runtime data store as an intermediary component that enables data pipelining between test scripts. This mediator allows tests written in PL/SQL or other DBMS procedural languages to share data without requiring Java programming, thus maintaining ease of operation while achieving data transfer capability. The runtime data store acts as a bridge between different test execution contexts.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Ease of operation

If users write test scripts in PL/SQL without Java knowledge, then ease of operation is improved, but data pipelining capability deteriorates

Engineering Contradiction:

Improveease of writing testsVSAvoiddata pipelining capability

Core Design Contradiction:

Ease of operationVSAdaptability or versatility

Solution Approach 1:

The patent enables PL/SQL test scripts to self-service data sharing by automatically interacting with the runtime data store through DBMS procedural language constructs. Tests can declare variables and procedures that automatically read from and write to the runtime data store without requiring external Java code, thus maintaining PL/SQL self-sufficiency while enabling data pipelining capability.

Inventive Principle:

Principle #25Self-service

3Adaptability or versatility

If a runtime data store is implemented for PL/SQL tests, then data pipelining capability is improved, but device complexity increases

Engineering Contradiction:

Improvedata pipelining capabilityVSAvoidsystem architecture complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements a universal runtime data store that serves multiple functions: it acts as a data repository for PL/SQL tests, enables data pipelining between tests, and integrates with the existing test execution framework. This multi-functional component reduces overall system complexity by consolidating data management responsibilities in a single structure that works across different test scenarios and languages.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentUS7836431B2Pipelining of input/output parameters between application tests written in a DBMS procedural language

Publication Date: 2010.11.16 ORACLE INT CORP

AI summary

To implement pipelining, data from a first test written in a DBMS procedural language (such as PL/SQL) is automatically passed to a second test which may or may not be in the same language. A user creates a container test to identify names of the two tests, and adds one or more procedure(s) with predetermined name(s), to identify dependencies between the tests. In the first test, to supply data for the second test, the user includes one or more additional procedure(s) of predetermined name(s), to support an interface to a runtime data store. The second test reads data from the runtime data store. In certain embodiments, an adapter extracts test names from the container test and uses each name to create an object for each test, and during execution of methods in each object a database call is issued.