Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EclipseLink/Development/DBWS/ParseDDLSprints"
< EclipseLink | Development | DBWS
(→Sprint #7: Resolve types left unresolved after parsing (ongoing)) |
|||
| Line 115: | Line 115: | ||
# in top-level StoredProcedure/Function: argument uses top-level types | # in top-level StoredProcedure/Function: argument uses top-level types | ||
# in top-level Object type: fields point to other Object types(s) | # in top-level Object type: fields point to other Object types(s) | ||
| − | + | #* also top-level Varray types | |
| − | + | #* also top-level Object tables | |
| − | + | #* and nested combinations of all three | |
---- | ---- | ||
Revision as of 14:20, 1 November 2011
DDL Parsing Sprints
Sprint #1: build CRUD Webservice from sample Table DDL (done)
- The goal of this sprint is to produce a functional end-to-end use case: a DBWS Web service that exposes a database table's CRUD (Create/Read(findByPK,findAll)/Update/Delete) lifecycle operations. The refactored DBWSBuilder utility takes a standard DBWS configuration file as input:
<?xml version="1.0" encoding="UTF-8"?> <dbws-builder xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <properties> <property name="projectName">emp</property> ... database properties </properties> <table catalogPattern="%" tableNamePattern="EMP" /> </dbws-builder>
prompt > dbwsbuilder.cmd -builderFile dbws-builder.xml -stageDir output_directory -packageAs wls emp.war
and produces a .war file suitable for deployment on WLS 10.3.5
- to reduce 'scope' of sprint: Table columns only use scalar types (i.e. no VARRAY, Nested tables, Object types)
| Workitem | Assigned to | Description | Estimate |
|---|---|---|---|
| DatabaseTypeBuilder | Mike Norman | pattern matching for schema and table names | ~2 days |
| grammar for Table | Mike Norman | ensure JSON grammar productions can describe a Table | ~3 days |
| Model objects for Table | Mike Norman | ensure model objects fully represent a Table as an in-memory object-graph | ~3 days |
| Visitor for Table | Dave McCann | ensure Table object-graph can be 'walked' from root to leaves | ~4 days |
| Generate ORM map from Table visitor | Dave McCann | build OR project/descriptors/mappings to represent Table entity from database POV | ~3 days |
| Generate OXM map from Table visitor | Dave McCann | build OX project/descriptors/mappings to represent Table entity from SOAP msg POV | ~3 days |
| Generate Schema for Table | Dave McCann | build XML schema to represent Table entity (to be used in WSDL) | ~3 days |
| Generate WSDL for Webservice | Dave McCann | build WSDL schema to represent CRUD operations | TBD (small # of days: can leverage existing DBWSBuilder code) |
Sprint #2: build Webservice from simple Stored Procedure/Function (done)
- The goal of this sprint is to produce a functional end-to-end use case: a DBWS Web service that exposes a StoredProcedure (or StoredFunction). To manage the scope and complexity of this sprint, only scalar argument types will be supported.
- backlog from Sprint #1
- custom SQL
- SQL nested under TableOperations
- make sure that ProcedureOperations nested under TableOperations work
- for both non-Oracle and Oracle platforms
- test for IN, OUT, INOUT and RETURN arguments
- backlog from Sprint #1
Sprint #3: build Webservice from simple Stored Procedure/Function in a PL/SQL package (done)
- Extend the work from Sprint #2: StoredProcedures with only scalar arguments, but these procedures are not located at TOPLEVEL, they are inside of PL/SQL packages.
- backlog from Sprint #2:
- Handle resultSet from Stored Procedure via SYS_REFCURSOR OUT parameter (bug# 356617)
- Handle OUT parameter(s) for Stored Functions (bug# 356637)
- backlog from Sprint #2:
Sprint #4: build Webservice from Stored Procedure/Function in a PL/SQL package (done)
- Extend the work from Sprint #3: StoredProcedures with PL/SQL Record types as arguments (completed)
- backlog from Sprint #3 (tbd)
- test for IN, OUT, INOUT and RETURN arguments
Sprint #5: build Webservice from Stored Procedure/Function in a PL/SQL package (done)
- Extend the work from Sprint #4: StoredProcedures with PL/SQL Collection types as arguments (complete)
- backlog from Sprint #4
- create & drop DDL for 'shadow' types
- include support for PL/SQL Record types that include PL/SQL Collection types and vice-versa
- backlog from Sprint #4
Sprint #6: support Advanced Oracle types (ongoing)
- Add support for Advanced Oracle types: OBJECT's, VARRAY's and Nested tables (started)
- backlog from Sprint #5 (tbd)
- have to re-visit existing Table and StoredProcedure support (TOPLEVEL and inside PL/SQL packages)
Sprint #7: Resolve types left unresolved after parsing (ongoing)
After parsing a top-level artifact (StoredProcedure/Function, Package, Object type, etc.) some nested database types may be unresolved as they may refer to other top-level artifacts. The following is a list of use cases:
- in PL/SQL package: types that use %ROWTYPE and %TYPE macros: point to columns of tables (in this or granted schemas)
- in top-level StoredProcedure/Function: argument uses top-level types
- in top-level Object type: fields point to other Object types(s)
- also top-level Varray types
- also top-level Object tables
- and nested combinations of all three
Sprint #8: support REF CURSORs (est. 3 weeks)
- Add support for PL/SQL REF CURSORs
- backlog from Sprint #7 (tbd)
- both weakly-typed and strongly-typed