EDMcompilerProject file

An EDMcompilerProject file allows  QUERY, RULE or MAPPING schemas to be created from multiply input files. The default file extension for an EDMcompilerProject file is".xpxprj",".qexprj",".rexprj" for the various EDMcompilerProject types (mapping, query, rule).  The layout of an EDMcompilerProject file is shown below

SOURCE_FILES_PATHS
"a folder path"
"another folder path"
END_SOURCE_FILES_PATHS
SOURCE_FILES 
 QUERY_SCHEMA xxx;
 GLOBAL
 ....
 ...
 END_GLOBAL;
 --#include "filename"
 ....
 END_QUERY_SCHEMA; 
END_SOURCE_FILES; 

The SOURCE_FILES_PATHS points to the different paths that the EDMcompiler can use to find the included files. Also, the SOURCE_FILES includes the actual header and the include files within the query.  An Include directive is implemented with the following format:

--#include "fileName"

When creating a EDMcompile project file  the following rules must be followed

1. SOURCE_FILES_PATHS, END_SOURCE_FILES_PATHS, SOURCE_FILES and END_SOURCE_FILES are case insensitive

2. The"fileName" must be embedded in double quotes to enable all legal file names.
3. The include directive can be placed anywhere outside a comment in any source files.
4. There can be any number of include directives in a source file and include files can be nested to any depths.

By default, each beginning and end of a source file in the resulting LongForm will be marked. There is an option NO_SHORT_FILE_NAME_IN_LONG_FORM to avoid this marking in the LongForm. The options ADD_SHORT_FORM_LINE_NUMBERS and ADD_LONG_FORM_LINE_NUMBERS can be used to add to the LongForm the ShortForm and/or the LongForm line numbers.

NOTE: The processing of the INCLUDE directives will only be performed in the"context of an EDMcompilerProject".

The resulting compilation diagnostics will be enhanced with the following:

• A list of all ShortForm files constituting the LongForm, will be listed in the order of the occurrences in the LongForm.
• Each diagnostic message will list the line number in the LongForm and the line number in the actual ShortForm file.

NOTE: For readability purposes it is better to add the content of the SOURCE_FILES block into another file, filename.main, and than place the the filename in the SOURCE_FILES block, see below

SOURCE_FILES_PATHS
"a folder path"
"another folder path"
END_SOURCE_FILES_PATHS
SOURCE_FILES 
"filename.main"
END_SOURCE_FILES; 

Pragma directive:

Pragma directive in EDMquerySchema, EDMruleSchema and EDMmapSchema (EDMschemaMap) to enable "passing aggregates by reference" instead of "PASS_AGGREGATES_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) "passing aggregates by reference". The format of the pragma is:

--$EPP{pragma "VM.pass_aggregates_by_reference"="true"}

All "elements" in the Pragma directive is case insensitive. The actual value must be either true or false. The Pragma directive must be within (between)  the actual SCHEMA - END_SCHEMA tokens.It is a good practice to place the Pragma directive right after the actual SCHEMA token. 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 because "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.