Releases: jamessimone/apex-rollup
Even Safer Scaling
- Make deferred rollup operations even safer by consolidating logic for when a Rollup is queued, batched, or run synchronously.
- Added additional scripts to aid in testing within sandboxes which contain more than just Rollup's tests.
hashCode update & Deferred rollup bugfix
- Added
RollupTestUtils.cls
to centralize mocking Id creation - Added
RollupRecursionItem.cls
to properly encapsulateequals()
andhashCode()
implementation - big thanks again to @gdoenlen for contributing on this one - Fixed an issue with the
deferredRollups
section that could lead to a gack when deferred rollups are being processed (thanks to Katherine West for reporting this one!)
Full Recalc Bugfixes, Logging & FIRST/LAST quality of life updates
-
Fixes #95 by fixing restrictiveness level for RollupEvaluator
-
Tweaks for #88 to fully support automated pipeline
-
Updating
batch
method to properly intake RollupInvocationPoint -
Fix Apex issue where not all code paths were setting CalcItem__c on Rollup__mdt synthetic records
-
Added baseline logging and new
RollupControl__mdt.IsRollupLoggingEnabled__c
field to toggle on/off. In particular, there's an emphasis on providing information in two parts - the "gathering" phase ofRollup
, before it goes async, and the "acting" part ofRollup
, with information about each parent-level item being rolled up. This toggle should only be enabled while testing, as it will balloon your debug log size and negatively impact performance. -
patched holes in current RollupCalculator functionality for full recalculation routes that weren't already covered (so, everything besides average/first/last)
-
Added baseBaseCalculation method in RollupCalculator to deal with the possibility of rollups where the evaluator filters out all calc items necessitating a full recalc - which would not have happened for String and Number-based rollups previously
-
Fixes #97 by properly handling unwriteable fields in recursive check
-
Thanks to @mickster04, who added safe guards when migrating from DLRS (#98)
Performance Tweaks
- Additional cleanup spurred by having temporarily moved each Rollup's instance
eval
evaluator variable to be non-final, which in addition to being bothersome exposed some hand-off issues between the batch class version of Rollup and its queueable inner class. This also revealed a few spots where theRollupControl__mdt
was being fetched twice for no reason. - Introduced an explanatory comment on the
Database.executeBatch
section of Rollup'srunCalc
method, as a newcomer might find themselves ... wondering ... why we were re-initializing the class 😅🔍 - small heap size improvement in
RollupEvaluator
(cc @ssk42, in the event you had broken ground there, but this shouldn't be a merge-conflict scenario of any kind); holdover from #91; empty object pattern (AlwaysTrueEvaluator
) should always be implemented as a singleton
Automate Build Pipeline & Rollup Control Updates
- Fixes #88 by automating build pipeline for package version creation, promotion, and replacement in README
- BREAKING CHANGE
RollupControl__mdt.MaxQueryRows__c
updated toRollupControl__mdt.MaxNumberOfQueries__c
- this field was improperly named as part of v1.1.2, to my chagrin. The concept for "Max Query Rows" was already encapsulated inRollupControl__mdt.MaxLookupRowsBeforeBatching__c
field - Fixed a bug reported by Katherine West where
RollupFullBatchRecalculator
would not properly reset field values when batching - this issue was exacerbated by the "Max Query Rows" updates, above; batching was happening way earlier than it should have because the limit thatRollup
was looking to was 100 instead of 3000 (the default forMaxLookupRowsBeforeBatching__c
- Some more tooling on how
RollupEvaluator
gets initialized/passed around withinRollup
itself, specifically in regards to the recursion detection released in #91
DLRS conversion script & recursion detection
- Recursion detection added to prevent updates that don't update fields used in rolling up from re-triggering the rollup async work. Not all code paths currently support early-exit for recursive updates - notably, Full Record Set-based rollups, Grandparent rollups, and/or Ultimate Parent (hierarchical) rollups
- additional test coverage for #87 - integration tests for trigger-based rollups added, including some interesting bugfixes for rollups where insert/update/delete (etc ...) all occur within the same Apex transaction
- README updates to fix documentation for #90 by adding information about
Concat Delimiter
field - @jongpie put together a great script to close #84 - DLRS rules can now be auto-converted to Rollup metadata 🎉! More information can be found in the
Setup
section of the Readme
Better support for after update flows, concat distinct bugfixes for delete
- Fixes #85 by properly supporting CONCAT_DISTINCT on delete
- Refactored recalculation app so that Order By field could be included
- Added ability to select CMDT
Rollup__mdt
in full recalculation app, piggybacking off of #79 - BREAKING CHANGE - base Rollup invocable action and bulk Rollup invocable action now require you to stipulate the SObject type for two different collection variables, though the new one ,
Prior records to rollup
, is strictly optional on anything other than after update record-triggered flows. Note - while the Flow engine would have you believe that your Flows are locked after upgrading (because thePrior records to rollup
collection variable type is both locked and required), if you keep your Flows in source control, you can still edit the XML and re-push the flow without having to recreate the Apex action(s):
<dataTypeMappings>
<typeName>T_oldRecordsToRollup</typeName>
<typeValue>REPLACE_THIS_WITH_YOUR_SOBJECT_API_NAME</typeValue>
</dataTypeMappings>
- Invocable / full recalculation app code routes now offer earlier validation for invalid rollups - like FIRST/LAST without an Order By field stipulated
Hierarchy Rollups & FIRST/LAST bugfixes
- added support for hierarchical (ultimate parent) rollups, either in conjunction with grandparent rollups or done separately. It's now possible to rollup values to the ultimate Parent Account, for example, and any other hierarchy-based or lookup field pointing to the same object
- fixes #80 by properly including Calc Item Where Clause in FIRST/LAST queries
- bugfix for currency/multi-decimal exclusions using zero in a Calc Item Where Clause - no longer have to use the exact decimal precision (
0.0
,0.00
,0.000
, etc) when filtering on zero - Further fixes for #80 reported by Katherine West - rollups should update lookup items if the current value would be excluded due to the calc item where clause, but the old item's value would not be excluded.
- Fixes #82 - with caveats about the need to extend the LWC to support all of the fields necessary - by enforcing validation rules for performFullRecalculation method in Rollup
CMDT Datatable for Recalculate Rollup App
- Fixes #75 by removing named export from recalculate rollup LWC, which breaks
event
targeting in Locker (thanks to @manuel-jasso & @ekashida for their support on this one) - Fixes #77 by updating rollup action picture to properly describe when to use INSERT / UPDATE
- Actual fix for #74 by removing all instances of DML on Opportunity object within unit tests
- Thanks to @jongpie for doing the fix for #78 - added CMDT-driven datatable to Recalculate Rollup app 🎉
- Fixed several bugs with
Calc Item Where Clause
where usage of the polymorphic Owner/Type fields on SObjects could break the filtering, particularly when the rollup was started from the parent object