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/PLSQLStoredFunctions"
< EclipseLink | Development | DBWS
(→Complex PL/SQL datatypes as parameters (and return argument) for StoredFunctions) |
|||
| Line 1: | Line 1: | ||
== Complex PL/SQL datatypes as parameters (and return argument) for StoredFunctions == | == Complex PL/SQL datatypes as parameters (and return argument) for StoredFunctions == | ||
| − | As described in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=275156 bug 27516], the specific | + | As described in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=275156 bug 27516], the specific <code>DatasourceCall</code> behaviour that handles complex PL/SQL datatypes as parameters is in <code>PLSQLStoredProcedureCall</code>, making it un-available to a sub-class of <code>StoredFunctionCall</code> |
[[Image:Call_classdiagram.png]] | [[Image:Call_classdiagram.png]] | ||
| + | |||
| + | === Refactoring <code>DatasourceCall</code> Hierarchy === | ||
| + | In order to better handle complex PL/SQL datatypes as parameters, the <code>DatasourceCall</code> hierarchy needs to be refactored. In addition to 'starving' <code>StoredFunctionCall</code>'s from handling complex parameters, the current code <b><i>leaks</i></b> internal implementation details to the surrounding classes: a parameter's name is held in a separate array from the array that holds (at the same index) the <code>DatabaseFields</code>'s that describe the parameter. Additionally, the parameter at index <tt>0</tt> is 'special', representing the return argument for <code>StoredFunctionCall</code>'s. | ||
Revision as of 10:58, 25 January 2010
Complex PL/SQL datatypes as parameters (and return argument) for StoredFunctions
As described in bug 27516, the specific DatasourceCall behaviour that handles complex PL/SQL datatypes as parameters is in PLSQLStoredProcedureCall, making it un-available to a sub-class of StoredFunctionCall
Refactoring DatasourceCall Hierarchy
In order to better handle complex PL/SQL datatypes as parameters, the DatasourceCall hierarchy needs to be refactored. In addition to 'starving' StoredFunctionCall's from handling complex parameters, the current code leaks internal implementation details to the surrounding classes: a parameter's name is held in a separate array from the array that holds (at the same index) the DatabaseFields's that describe the parameter. Additionally, the parameter at index 0 is 'special', representing the return argument for StoredFunctionCall's.