Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

EclipseLink/Development/DBWS/ParseDDLDS

< EclipseLink‎ | Development‎ | DBWS
Revision as of 16:35, 31 May 2011 by Unnamed Poltroon (Talk) (Parsing DDL for Metadata)

Parsing DDL for Metadata

The primary job of the DBWSBuilder utility is to extract metadata from the database about some artifact (i.e. a Table or a StoredProcedure) that is to be used as the basis of a (JAX-WS compliant) Web Service. The DBWSBuilder translates the information (fields, arguments, scalar or complex datatypes, etc.) into DBWS runtime artifacts (e.g. EclipseLink Project XML files, JAX-WS Provider class, etc.) Thus it is crucial that DBWSBuilder get complete and accurate metadata from the database.

For Oracle databases, DBWSBuilder uses a modified cut-down version of the JPublisher classes to send SQL queries to Data Dictionary views (ALL_OBJECTS, ALL_ARGUMENTS, etc.) that is then converted to an in-memory object-graph of all relevant information about the specific database artifact required for the Web Service. This object-graph is then walked and the required DBWS runtime artifacts generated.

Unfortunately, the information in the Data Dictionary views can be (under certain circumstances) incomplete or inaccurate, or the in-memory object-graph constructed from the views can be distorted. For example, an argument to a StoredProcedure may have a default value assigned to it, thus making it optional. This in turn means that the calling sequence can change in that fewer arguments need be passed in:

CREATE OR REPLACE PACKAGE SOMEPKG AS
 
  TYPE EMP_REC IS RECORD(
    EMPNO EMP.EMPNO%TYPE,
    FNAME EMP.FNAME%TYPE,
    LNAME EMP.LNAME%TYPE
  );
 
  PROCEDURE DOSOMETHING(MYREC IN OUT EMP_REC, STUFF IN VARCHAR2,
    P_EMPNO IN NUMBER := 20, FLAG IN BOOLEAN DEFAULT FALSE,
    WHATEVER IN VARCHAR2 DEFAULT 'bogus');
END;

The object-graph created 4 StoredProcedure representations:

DOSOMETHING(MYREC,STUFF)
DOSOMETHING(MYREC,STUFF, P_EMPNO)
DOSOMETHING(MYREC,STUFF, P_EMPNO, FLAG)
DOSOMETHING(MYREC,STUFF, P_EMPNO, FLAG, WHATEVER)

however, there are an additional 4 possibilities:

DOSOMETHING(MYREC,STUFF, FLAG)
DOSOMETHING(MYREC,STUFF, WHATEVER)
DOSOMETHING(MYREC,STUFF, FLAG, WHATEVER)
DOSOMETHING(MYREC,STUFF, P_EMPNO, WHATEVER)

This also highlights a problem where the number of in-memory objects could expand geometrically 2N

Back to the top