|
edmi
|
EDM application programmer's info on EDM compiler, see also EDM compiler
See also:
The EDM compiler compiles 2 types of source:
Lorens ipsum.
GENERIC and GENERIC_ENTITY handling is possible to manipulate to get better control of reflection anmd code generation.
refer to relevant edm_compiler_pragma for details.
NOTE: GENERIC_ENTITY is not (yet) implemented fully, it is hjandled seomwhat by compiler, but EDMVM will treat GENERIC and GENERIC_ENTITY identically.
The following types of EXPRESS (EXP) schemata is handeled:
Look up functions in EDM compiler for details.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin elementum ultrices arcu consectetur laoreet. Vivamus mauris ante, lacinia eget accumsan et, iaculis et tortor.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin elementum ultrices arcu consectetur laoreet. Vivamus mauris ante, lacinia eget accumsan et, iaculis et tortor.
The following types of EXPRESS-X (XPX) schemata is handeled:
Look up functions in EDM compiler for details.
Pragmas are used in EXPRESS/EXPRESS-X source code to modify default behaviour of the EDM system. Syntax pattern is usually:
--$EDM{pragma "<group>.<name>.<item>"="<value>"}
Unless otherwise specified, you cannot turn pragmas on and off or change pragma value within the same code unit (file) If they are supplied AFTER the code itself they cannot be trusted to have the desired effect Hence always place pragmas in the beginning of the source file.
IMPORTANT: if you supply multiple pragmas in sequence, you must have a blank line after each pragma, due to a parser pecularity!!!!
--$EDM{pragma "COMPILER.ERROR_SEVERITY.C[nnnn]"=[value]}
Set the error severity for the compiler error nnnn to one of the following values:
"non" or "ignore"
"msg" or "message"
"wrn" or "warning"
"err" or "error"
Value is not case sensitive, so WRN works as well as "wrn". Example:
-- Refers to compiler error C3174: Type label for GENERIC_ENTITY is not handled. Default severity is ERROR which will prevent storage of the schema.
-- Set severity to WARNING to have compiler store the schema in EDM database as a dictionary model in the normal way.
--$EDM{pragma "COMPILER.ERROR_SEVERITY.C3174"="wrn"}
It is possible to redefine by supplying edm_compiler_pragma as follows:
--$EDM{pragma "COMPILER.GENERIC_HANDLING.FREE_TYPE_LABEL"=[false|true]} (default=false)
-- true : bypass the type_label rules, allowing non-standard use of type_label for meta-data
--$EDM{pragma "COMPILER.GENERIC_HANDLING.DEFAULT_TYPE_LABEL"=[value]
-- empty string (default) : if no type_label specified type_label will be UNSET
-- non-empty string : any GENERIC not having a type label will get this value for its type_label
It is possible to redefine by supplying edm_compiler_pragma as follows:
--$EDM{pragma "COMPILER.GENERIC_ENTITY_HANDLING.FREE_TYPE_LABEL"=[false|true]} (default=false)
-- true : bypass the type_label rules, allowing non-standard use of type_label for meta-data
--$EDM{pragma "COMPILER.GENERIC_ENTITY_HANDLING.DEFAULT_TYPE_LABEL"=[value]
-- empty string (default) : if no type_label specified type_label will be UNSET
-- non-empty string : any GENERIC not having a type label will get this value for its type_label
NOTE: As GENERIC_ENTITY is not (yet) implemented fully, you will need to redefine error severity for compiler err Cnnnn to get GENERIC_ENTITY handling through the compiler. See edm_compiler_pragma how to do this.
--$EDM{pragma "COMPILER.TRACE_MASK.<item>"=[value]}
--$EDM{pragma "COMPILER.EDMEXTENSIONS.<item>"=[value]}
Lorens ipsum
Pragma directive in EDMquerySchema, EDMruleSchema and EDMmapSchema (EDMschemaMap) to enable "passing aggregates by reference" instead of "passing aggregate by value". In EDMexpressX, the default way of "passing aggregates" is "by value". This means that (almost) each time an aggregate is stored or used as a parameter in a function/procedure call, a copy of the actual aggregate is made, and the aggregateID of the new aggregate is stored or passed to the called function/procedure. This "method" is a performance killer and a large "virtual memory consumer". Hence, this should be avoided whenever possible. When using "pass aggregate by reference", only the aggregateID is stored or passed to the called function/procedure. Until now, the option "PASS_AGGREGATES_BY_REFERENCE" in the relevant EDMinterface operations or in the relevant EDMsupervisor commands, had to be used to enable the "pass aggregates by reference" method. A pragma directive is introduced in all kinds of EDMexpressX schemata to enable (and disable) "PASS_AGGREGATES_BY_REFERENCE". The format of the pragma is :
--$EPP{pragma "VM.pass_aggregates_by_reference"="true"}
note that
No warning/error message is produced when more than one "VM.pass_aggregates_by_reference" pragma is specified in the same schema. In such cases, the last one will be the only giving an effect at run-time. Hence, it is just confusing to have more than one "VM.pass_aggregates_by_reference" pragma in the same schema.
The "old way" of specifying "PASS_AGGREGATES_BY_REFERENCE" is still available, but it is recommended to use the Pragma directive instead of the "old way" because the way of "passing aggregates" is an attribute of the actual schema, decided at schema design time, and not an option that can/should be enabled/disabled at run-time.
Lorens ipsum.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin elementum ultrices arcu consectetur laoreet. Vivamus mauris ante, lacinia eget accumsan et, iaculis et tortor.
Cut&Paste just to have a template....
From XPX:
FUNCTION xpfCppPluginInvoke( dll_path : STRING, -- path to plugin file, absolute or relative to executing appserver
dll_name : STRING, -- name of plugin file including extension
dll_function: STRING, -- plugin main function
...arguments... -- plugin function arguments
)
status : INTEGER;
From C/C++:
EdmiError edmiRemoteExecuteCppMethod( SdaiServerContext serverContextId,
SdaiString remoteRepositoryName,
SdaiString remoteModelName,
SdaiString pluginPath,
SdaiString pluginName,
SdaiString methodName,
SdaiOptions options,
SdaiInteger nOfParameters,
RemoteParameter *parameters,
SdaiIOstream ioStream,
SdaiInteger nOfReturnValues,
RemoteParameter *returnValues,
allocMemory getMemoryForReturnValues,
void *allocFromObject,
SdaiInvocationId *edmiInvocationId
);
The dll_function / methodName parameter works as follows:
If a plugin is invoked without being loaded beforehand, it is loaded, invoked and unloaded in a single xpfCppPluginInvoke invocation.
1.8.20