INC-156818 · Issue 628466
Materialization uses time limit boundary for query
Resolved in Pega Version 8.6
After turning on Materialization for pyIHSummary and OfferOutcomesForPast45Days datasets, an SQL query was taking an excessive amount of time and causing multiple alerts in the logs. Investigation traced the issue to database partitioning, specifically that running a query where the pyOutcomeTime range spanned multiple partitions was causing the indexes for all partitions in the range to be opened. To resolve this, the query has been updated with a DSS to support a partition size of min(pxOutcomeTime) to limit the time range to querying day by day, or hour by hour, or any other chronology unit specified. If there are no records for the current limit, then it will look at the next partition. This should prevent the query from needing to open more than 1 or 2 partitions.
INC-156818 · Issue 628467
Materialization uses time limit boundary for query
Resolved in Pega Version 8.5.4
After turning on Materialization for pyIHSummary and OfferOutcomesForPast45Days datasets, an SQL query was taking an excessive amount of time and causing multiple alerts in the logs. Investigation traced the issue to database partitioning, specifically that running a query where the pyOutcomeTime range spanned multiple partitions was causing the indexes for all partitions in the range to be opened. To resolve this, the query has been updated with a DSS to support a partition size of min(pxOutcomeTime) to limit the time range to querying day by day, or hour by hour, or any other chronology unit specified. If there are no records for the current limit, then it will look at the next partition. This should prevent the query from needing to open more than 1 or 2 partitions.
INC-156818 · Issue 628465
Materialization uses time limit boundary for query
Resolved in Pega Version 8.4.5
After turning on Materialization for pyIHSummary and OfferOutcomesForPast45Days datasets, an SQL query was taking an excessive amount of time and causing multiple alerts in the logs. Investigation traced the issue to database partitioning, specifically that running a query where the pyOutcomeTime range spanned multiple partitions was causing the indexes for all partitions in the range to be opened. To resolve this, the query has been updated with a DSS to support a partition size of min(pxOutcomeTime) to limit the time range to querying day by day, or hour by hour, or any other chronology unit specified. If there are no records for the current limit, then it will look at the next partition. This should prevent the query from needing to open more than 1 or 2 partitions.
SR-D89428 · Issue 550391
Data Flow StartTime uses locale timezone
Resolved in Pega Version 8.3.3
The start time of the dataflow was displayed in GMT instead of the operator locale timezone. This has been corrected.
SR-D77157 · Issue 544471
DataSet preview will use date instead of datetime
Resolved in Pega Version 8.3.3
While using a DataSet preview functionality, the date appeared as reduced by one day. This has been resolved by parsing date as 'date' instead of 'datetime' to avoid issues with timezone interactions.
SR-D77157 · Issue 544473
DataSet preview will use date instead of datetime
Resolved in Pega Version 8.4.1
While using a DataSet preview functionality, the date appeared as reduced by one day. This has been resolved by parsing date as 'date' instead of 'datetime' to avoid issues with timezone interactions.
SR-D89428 · Issue 550393
Data Flow StartTime uses locale timezone
Resolved in Pega Version 8.4.1
The start time of the dataflow was displayed in GMT instead of the operator locale timezone. This has been corrected.
SR-D89428 · Issue 550392
Data Flow StartTime uses locale timezone
Resolved in Pega Version 8.5
The start time of the dataflow was displayed in GMT instead of the operator locale timezone. This has been corrected.
SR-D77157 · Issue 544472
DataSet preview will use date instead of datetime
Resolved in Pega Version 8.5
While using a DataSet preview functionality, the date appeared as reduced by one day. This has been resolved by parsing date as 'date' instead of 'datetime' to avoid issues with timezone interactions.
INC-158813 · Issue 629486
Updated report handling for simulations using database output
Resolved in Pega Version 8.5.3
When running a simulation with a database table as the output destination, the pxObjClass property was not populating with a value in the results. This caused sub-reports to not be populated with data. Investigation showed that issue happened when the simulation output destination database table was inferred as an external table due to not having an exposed column for pzinskey. To resolve this, the pxObjClass and pxCreateDateTime properties, which were added to simulation output destination tables for compatibility with Report browser, will not be added to those tables when they are created. Instead, to address compatibility issues of simulation output destination classes with Report browse in the Customer Decision Hub, the pyDefaultSummaryReport has been brought up into the Data-Decision-StrategyExecution-ResultOutput class from the @baseclass.