Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Dynamic SQL Transformation

IP.com Disclosure Number: IPCOM000035553D
Original Publication Date: 2005-Jan-24
Included in the Prior Art Database: 2005-Jan-24
Document File: 3 page(s) / 88K

Publishing Venue

IBM

Abstract

Database products today do not necessarily implement an entire language standard; therefore applications may require product-specific persistence logic which would be bound to that application. Proposed is a method for separating product-specific persistence logic from the application and utilizing a generic language transformer that would allow any application whose persistence layer adheres to a standard to utilize the offerings of any database product without having to modify application code. Since the language transformer is generic, there is no tight relationship to the application; generic database queries made by an application could be transformed to product-specific queries dynamically at runtime.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

Dynamic SQL Transformation

    There exist several methods for developing applications that are not bound to a specific database. For example, a standardized language has been created to allow for common interfacing; development-time tools are available to aid in converting extended database statements to be compatible with other products; and design patterns to help dictate database-specific paths within the application. Binding database-specific logic to an application however introduces several significant problems: First, database-specific logic is bound to a single application, and it generally difficult to apply to multiple applications; Second, significant overhead exists with this model, especially when the persistence layer of the application must be modified when the product is out of development and into the test and service cycles; and finally, Updating the persistence layer of several different applications in order to allow them to be compatible with a new database type could be redundant. Described in this document is a novel approach to separating database-specific intricacies from an applications persistent manager, this allows the database-specific module to be pluggable and therefore available to any application Figure 3 . This solution not only allows applications to be more portable, but it also allows for faster adoption of new database products and enhancements. Rather than designing applications with persistence logic bound to specific databases Figure 2 , the persistence layer can be designed to generate more generic queries. These queries could, at runtime, be examined and manipulated prior to submission to the database for execution.

    By intercepting calls to the database API, a point within an application can be created where SQL can be observed and modified before it ever reaches a database system. At this point a transformation is performed on the SQL statement itself, converting the e...