INC-162649 · Issue 639397
DSS added for handling missing attachments
Resolved in Pega Version 8.3.6
When an S3 repository was configured as storage, some cases were not coming up in search and exception errors were seen in logs for a deleted attachment after every system restart/re-indexing of the search. Investigation showed these case objects were in the broken queue for pyFTSIncrementalIndexer due to a null pointer error encountered when indexing the attachment, and that the attachments were available in the repository but could not be read from the attachment repository during indexing. To resolve this, a new DSS setting has been added which allows selecting one of two behaviors:- Pega-SearchEngine indexing/distributed/fail_on_missing_attachment_file = true : broken item is generated, but with a meaningful error message. This is the default behavior - Pega-SearchEngine indexing/distributed/fail_on_missing_attachment_file = false: case is indexed, but without the problematic attachment. Error message is printed out to the logs.
INC-162968 · Issue 632476
Extra text seen in edit removed from Report Browser
Resolved in Pega Version 8.3.6
Extra Text reading 'BBBBBC' was appearing when editing Reports within Report Browser. This was due to extraneous test text input present within 'RRDataListHeader' HTML Rule, and this has now been removed.
INC-163160 · Issue 631476
Updated filter logic for filtering on a DateTime column
Resolved in Pega Version 8.3.6
When a class join was used in a report definition, the error "The Filter Logic used in the report is invalid" appeared while filtering rows of a report definition results on a DateTime column. This was a missed use case, and has been resolved by modifying pzGridSortPaginate to convert the data type value into the proper casing.
INC-169055 · Issue 646670
Performance improvements for database queries and archiving
Resolved in Pega Version 8.3.6
In order to improve the performance of database queries, repetitive unnecessary database calls have been removed, archival queries have been simplified, and diagnostic metrics were added. Optional batch requestors have been added to all archival services with their own DSS settings to allow processing more cases in parallel. It is recommended to create 2 additional indexes to help with the archival process. The indexes will be on:pegadata.pr_metadata (pyisparent, pyobjclass, pyarchivestatus) INCLUDE (pyinskey); pegadata.pr_metadata (pyisparent, pyarchivestatus) INCLUDE (pyinskey);
SR-D91660 · Issue 555722
Updated document ID handling for deleting indexes
Resolved in Pega Version 8.3.6
When trying to delete a document for index name "work*", intermittent errors were seen indicating an invalid index name or index does not exist value. This has been resolved by updating the handling for delete by ID.
SR-69015 · Issue 619995
Unescaping characters implemented for expressions
Resolved in Pega Version 8.3.6, Resolved in Pega Version 8.4.4, Resolved in Pega Version 8.5.3, Resolved in Pega Version 8.6
An issue where expression builder statements were evaluated differently at runtime than at testing has been resolved. Pega Platform expressions with String literals(that is, sequences of characters enclosed in quotation marks) now unescape characters in strategy shapes such as Set Property or Filter.
INC-203994 · Issue 698853
DSS added to handle merges with lower versions of Postgres
Resolved in Pega Version 8.7.1
After update, executing the batch campaign with volume constraint resulted in the second data flow DF_Wait failing with error message "ERROR: number of columns (1844) exceeds limit (1664)". This was due to the database set’s change (in 8.5) to use the database layer’s merge statement. Prior to that, the logic used "deletes and inserts". Depending on the version of Postsgres, the generated SQL statement for a merge statement is different. The “INSERT … ON CONFLICT … UPDATE” syntax is generated for Postgres 9.5+ AND when there is a PK constraint defined for the DB table. Otherwise, the complex UPSERT statement (old syntax) is generated, as was the case in this issue. This is a known issue in the Postgres server software where it mis-interprets the number of columns involved. i.e., it mistakenly counts the number of columns twice. As a result, the actual maximum columns allowed is only half of the official limit (1664). The same UPSERT statement does not cause the “exceeds limit” exception if there are 832 or fewer columns in the statement. To resolve this, an option has been provided to select between the “original logic” (deletes and inserts) and the “merge statements” logic by way of the DSS “decision/datasets/db/useMergeStatementForUpdates”. Setting “true” will use the merge statement logic, and setting “false” will use deletes and inserts. When the DSS is not defined, the default is "true" and the system will use merge statements in the form preferred by Postgres 9.5+.
INC-180246 · Issue 699700
Support for apostrophe added to keyword tokenization
Resolved in Pega Version 8.7.1
A keyword containing an apostrophe was not detected properly in Text extraction model. This has been resolved by updating the annotator used in the tokenization.
INC-193399 · Issue 688115
DSS added to handle merges with lower versions of Postgres
Resolved in Pega Version 8.7.1
After update, executing the batch campaign with volume constraint resulted in the second data flow DF_Wait failing with error message "ERROR: number of columns (1844) exceeds limit (1664)". This was due to the database set’s change (in 8.5) to use the database layer’s merge statement. Prior to that, the logic used "deletes and inserts". Depending on the version of Postsgres, the generated SQL statement for a merge statement is different. The “INSERT … ON CONFLICT … UPDATE” syntax is generated for Postgres 9.5+ AND when there is a PK constraint defined for the DB table. Otherwise, the complex UPSERT statement (old syntax) is generated, as was the case in this issue. This is a known issue in the Postgres server software where it mis-interprets the number of columns involved. i.e., it mistakenly counts the number of columns twice. As a result, the actual maximum columns allowed is only half of the official limit (1664). The same UPSERT statement does not cause the “exceeds limit” exception if there are 832 or fewer columns in the statement. To resolve this, an option has been provided to select between the “original logic” (deletes and inserts) and the “merge statements” logic by way of the DSS “decision/datasets/db/useMergeStatementForUpdates”. Setting “true” will use the merge statement logic, and setting “false” will use deletes and inserts. When the DSS is not defined, the default is "true" and the system will use merge statements in the form preferred by Postgres 9.5+.
INC-193632 · Issue 679172
Cassandra driver metrics exposed for performance troubleshooting
Resolved in Pega Version 8.7.1
By default Cassandra driver metrics are now enabled. Metrics can be disabled by setting the dnode/disable_driver_metrics prconfig parameter.