ELEMENT function (description?, implementation+) ATTRIBUTE name string title string
Attributes | Type | Mandatory | Default | Description |
---|---|---|---|---|
name | string | yes | n/a | Name of the function. It should be lowercased and a valid XML and SQL identifier. |
title | string | - | n/a | The title is a label text that should be displayed in the documentation of this object. |
A user defined function with the given name. The function may have at most one implementation for each supported DBMS.
ELEMENT implementation (param*, return?, code) ATTRIBUTE dbms string language string
Attributes | Type | Mandatory | Default | Description |
---|---|---|---|---|
dbms | string | - | generic | The name of the target DBMS. The value "generic" means that the definition is suitable for any DBMS. Usually this is used as a fall-back option for DBMS you haven't thought of when creating the database structure or for those that simply doesn't have the feature in question. |
language | string | - | n/a | The target programming language. This applies only to DBMS, that support more then one language. |
The implementation defines the function signature and source code. The number of parameters must be the same for each DBMS (and implementation tag).
If the attribute dbms is set to "generic", the XDDL-implementation may decide if the generic function definition is compatible with a certain DBMS. If it decides that the definition is not compatible, it may try to simulate the function. In that case the implementation may define the required syntax for the values of it's child elements "code", "param" and "return". If the definition does not match the required syntax, the XDDL-implementation may throw an error.
Note that the attribute "language" is DBMS-dependent. Most DBMS should at least support the value "SQL" as a language, while others may also include "Java", "C++" or more.
If no language is given, the default language is used. Note that this implementation may not check if the given language is really supported by the given DBMS.
For simulated functions the language attribute must be blank.
ELEMENT param EMPTY ATTRIBUTE name string type string mode string
Attributes | Type | Mandatory | Default | Description |
---|---|---|---|---|
name | string | yes | n/a | unique parameter name |
type | string | yes | n/a | DBMS-dependent data type |
mode | string | - | in | The attribute "mode" identifies the element as
|
A parameter definition as part of the function signature. The attribute "mode" identifies the behavior of the parameter. The type of the parameter is DBMS-dependent.
Example:
<function name="foo"> <implementation> <param name="p1" type="string" mode="in"/> <param name="p2" type="float" mode="inout"/> <param name="p3" type="int" mode="out"/> <return>int</return> <code>...</code> </implementation> </function> May be interpreted as: int foo ( string $p1, float &$p2, int &$p3 = null ) { ... }
Note that some DBMS only support input parameters (call by value). In that case the attribute "mode" must have the value "in". The implementation may throw an error if an unsupported definition is found.
ELEMENT return (#PCDATA)
The data type returned by the function. This setting is DBMS-dependent.
If no return element is defined, or if it is left empty, the return type defaults to "void", which means, the function doesn't return a value. If the function needs to return more then one value, it should use output-parameters instead. Be aware that in MySQL functions without a return value are called "methods".
ELEMENT code (#PCDATA)
The function body. The syntax of the content depends on the attributes for DBMS and programming language. If the DBMS is set to "generic", then this code is executed by the server application. In that case the implementation may define the required syntax itself. It is recommended, to limit the code to being the name of a function, that the implementation may call. All input parameters must be redirected to that function. Note that generic functions can't be used inside SQL-statements as these are not executed by the DBMS.
Thomas Meyer, www.yanaframework.net