Skip to content

[#14] Implement Computed Multiples

Sam Habiel requested to merge shabiel/YDBOctoVistA:ddl14-comp-mul into master

Fields that are computed multiples are essentially treated like long unlimited VARCHAR fields. The new function $$COMPMUL^%YDBOCTOVISTAM implements computed multiples and mirrors $$COMPEXP in design. There is a danger that the field will be too long and overflow an Octo query's 1MB record limit. However, for now, this danger is remote and we can deal with it if it happens. I didn't find any computed multiple in VistA that will evaluate to more than 1MB of data. An alternate implementation of computed multiples would be like VistA Word Processing fields, which would make them separate tables, with each line a seperate row, but this is quite complicated to implement as the records don't really exist.

Previously, the INCORRECT SQL definition of a computed multiple field looked like this:

CREATE TABLE `PRINT_TEMPLATE`(
...
`PRINT_FIELDS` CHARACTER(50) GLOBAL "^DIPT(keys(""PRINT_TEMPLATE_ID"")",
...
)
GLOBAL "^DIPT(keys(""PRINT_TEMPLATE_ID""))"
DELIM "^";

Now it looks like this:

CREATE TABLE `PRINT_TEMPLATE`(
...
 `PRINT_FIELDS` VARCHAR EXTRACT "$$COMPMUL^%YDBOCTOVISTAM(.4,1620,keys(""PRINT_TEMPLATE_ID""))",
...
)
GLOBAL "^DIPT(keys(""PRINT_TEMPLATE_ID""))"
DELIM "^";

The other major change this commit makes is that all EXTRACT fields do not emit "GLOBAL" anymore, as this is not needed. All information needed to get the data is after "EXTRACT".

Previously, a few fields in PRINT_TEMPLATE looked like this:

 `PRINT_FIELDS` CHARACTER(50) GLOBAL "^DIPT(keys(""PRINT_TEMPLATE_ID"")",
 `ROUTINE_INVOKED` CHARACTER(1) GLOBAL "^DIPT(keys(""PRINT_TEMPLATE_ID""),""ROU"")" EXTRACT "$E($G(^DIPT(keys(""PRINT_TEMPLATE_ID""),""ROU"")),1,13)",
 `PREVIOUS_ROUTINE_INVOKED` CHARACTER(1) GLOBAL "^DIPT(keys(""PRINT_TEMPLATE_ID""),""ROUOLD"")" EXTRACT "$E($G(^DIPT(keys(""PRINT_TEMPLATE_ID""),""ROUOLD"")),1,13)",
 `COMPILED` CHARACTER(3) GLOBAL "^DIPT(keys(""PRINT_TEMPLATE_ID"")" EXTRACT "$$COMPEXP^%YDBOCTOVISTAM(.4,1819,keys(""PRINT_TEMPLATE_ID""))",

Now they look like this, with GLOBAL removed (note first one is a computed multiple):

 `PRINT_FIELDS` VARCHAR EXTRACT "$$COMPMUL^%YDBOCTOVISTAM(.4,1620,keys(""PRINT_TEMPLATE_ID""))",
 `ROUTINE_INVOKED` CHARACTER(1) EXTRACT "$E($G(^DIPT(keys(""PRINT_TEMPLATE_ID""),""ROU"")),1,13)",
 `PREVIOUS_ROUTINE_INVOKED` CHARACTER(1) EXTRACT "$E($G(^DIPT(keys(""PRINT_TEMPLATE_ID""),""ROUOLD"")),1,13)",
 `COMPILED` CHARACTER(3) EXTRACT "$$COMPEXP^%YDBOCTOVISTAM(.4,1819,keys(""PRINT_TEMPLATE_ID""))",

Other changes:

  • Increment version number for users to know that this is a new version functionality wise.
  • Bandaid for [#9 (closed)], since I used that functionality in testing: initialize ERRORCOUNT varaible. I didn't go through a stock FOIA VistA to verify the SQLI functionality is correct, so I cannot close #9 (closed) yet, but I did enough work for it to run reliably on my system.
  • I discovered that SQLI emits a list of FOREIGN KEYS for each file. I added a TODO. Issue #13 (closed) will convert the TODOs to issues.
  • Remove this TODO: don't use $P here, use something else to get the rest of the line. $P is actually correct, and is what Fileman uses.
Edited by Sam Habiel

Merge request reports