Skip to content

Releases: jamessimone/apex-rollup

Even Safer Scaling

13 May 21:35
6fc7c23
Compare
Choose a tag to compare
  • 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

12 May 19:52
4e86038
Compare
Choose a tag to compare
  • Added RollupTestUtils.cls to centralize mocking Id creation
  • Added RollupRecursionItem.cls to properly encapsulate equals() and hashCode() 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

11 May 14:09
159519e
Compare
Choose a tag to compare
  • 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 of Rollup, before it goes async, and the "acting" part of Rollup, 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

05 May 15:23
e0bc123
Compare
Choose a tag to compare
  • 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 the RollupControl__mdt was being fetched twice for no reason.
  • Introduced an explanatory comment on the Database.executeBatch section of Rollup's runCalc 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

04 May 21:05
361e899
Compare
Choose a tag to compare
  • Fixes #88 by automating build pipeline for package version creation, promotion, and replacement in README
  • BREAKING CHANGE RollupControl__mdt.MaxQueryRows__c updated to RollupControl__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 in RollupControl__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 that Rollup was looking to was 100 instead of 3000 (the default for MaxLookupRowsBeforeBatching__c
  • Some more tooling on how RollupEvaluator gets initialized/passed around within Rollup itself, specifically in regards to the recursion detection released in #91

DLRS conversion script & recursion detection

02 May 21:43
89e90bb
Compare
Choose a tag to compare
  • 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

26 Apr 14:04
2448d6b
Compare
Choose a tag to compare
  • 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 the Prior 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

21 Apr 14:00
f311cae
Compare
Choose a tag to compare
  • 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

16 Apr 19:57
0117d8b
Compare
Choose a tag to compare
  • 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

Better Async Processing & Test Updates

10 Apr 23:59
Compare
Choose a tag to compare
  • Fixes #74 by migrating away from the use of the Opportunity object in almost all of the RollupTests tests
  • Fixes #69 by alternating between async contexts (when necessary), and not re-queueing / re-batching when already async unless necessary due to limits