Skip to content

Releases: jamessimone/apex-rollup

v1.5.68 - RollupCalcItemReplacer bugfix

31 May 21:53
f3835a2
Compare
Choose a tag to compare
  • Removes chance for row with duplicate Id possibility in RollupCalcItemReplacer, reported by @fefris

v1.5.67 - RollupRelationshipFieldFinder bugfix

19 May 13:12
dac8467
Compare
Choose a tag to compare
  • Fixes #445 by properly protecting against improper field access in RollupRelationshipFieldFinder

v1.5.66 - Small Cleanup

18 May 20:07
b0ca121
Compare
Choose a tag to compare
  • Slight cleanup on some RollupOrderBy__mdt transformations
  • Fixes an issue raised in #443 related to invalid casts being performed in RollupCalculator

Release notes for v1.5.65 (#441):

  • Fixes #440 by including an internal, opt-in plugin, which updates .RollupSettings__c.BypassValidationRules__c so that validation rules can make exceptions for when Apex Rollup is the one updating records. For more info, see the Rollup Plugins section of the README - this (internally included) plugin allows subscribers to pre/post-process record synchronously, allowing for:
    • additional updates to the Database.DMLOptions that Apex Rollup uses to be made pre-update
    • any additional pre-processing before parent records are updated can be made
    • any additional post-processing that you would prefer to do synchronously on parent records can be made (I recommend using the Rollup Callback plugin to respond to updates in an asynchronous fashion, but it's always good to have options!). Keep in mind that hooking into post-processing using the synchronous version means that CPU and heap limits from Apex Rollup's processing will still be in effect.

v1.5.64 - Grandparent Rollup Optimizations

04 May 19:21
5cb1693
Compare
Choose a tag to compare
  • Added an optimization for grandparent rollups triggered by full recalc runs - now, when a full recalc rollup has already queried up the hierarchy, we can assume all children are already present in RollupRelationshipFieldFinder, instead of re-traversing the entire hierarchy. This fixes an issue reported in #414 where the finder was chewing through too many queries in a bulk full recalc with several grandparent rollups configured
  • Fixed up RollupFlowBulkProcessor issue from #437 (which was temporarily reverted in #438)
  • Added some additional optimizations for when RollupCalcItemReplacer actually runs
  • Fixes issue reported by Joseph Mason where non-polymorphic Type fields were not being queried properly for full recalcs
  • Fixes an issue reported by @solo-1234 where rollup order by fields were not being queried properly for full recalcs created from Flow when a rollup was triggered by the parent

v1.5.62 & v1.5.63 - ACM Currency Field Mapping Support

21 Apr 16:15
a46390d
Compare
Choose a tag to compare
  • Introduced Rollup__mdt.CurrencyFieldMapping__c to allow ACM-enabled orgs to use custom Date/Datetime fields (or the overriding of the default Date fields used when deciding how to convert currency amounts for Opportunities, Opportunity Line Items, Opportunity Line Item Schedules, and Opportunity Splits). This field can be comma-separated if you are pointing to a parent-level field; at this point and time, it only supports going up one "level" though
  • Fixed a bug reported on SFXD where the RollupCalcItemReplacer was getting a little too optimistic with queries when a field used in a Calc Item Where Clause was present but null
  • Further bulk optimizations:
    • slightly better handling in RollupFlowBulkProcessor
    • removed some getTypeName() calls from what gets output to the rollup logs to further reduce CPU time

v1.5.61 - Further Heap Reductions

09 Apr 04:28
3715b46
Compare
Choose a tag to compare
  • Vastly simplified Rollup.toString, avoiding unncessary heap consumption when logging is disabled

v1.5.60 - System.AccessLevel updates

07 Apr 20:17
bdaaae1
Compare
Choose a tag to compare
  • Updates to avoid serialization issues with System.AccessLevel
  • Further optimizations:
    • updates to RollupMetaPicklists to avoid excessive validation calls
    • updated a few regexes to avoid undue CPU time
    • less reliance on System calls that can be expensive
    • avoided calculating large map entries when logging is disabled to avoid heap size increases

v1.5.59 - RollupEvaluator no longer case-sensitive, added Rollup.modifyMetadata method

05 Apr 17:41
ad58854
Compare
Choose a tag to compare
  • Where clauses are no longer case sensitive when writing field names
  • Added modifyMetadata to allow instances of Rollup to do things like transform a rollup called from Apex into a group by rollup

v1.5.58 - RollupRepository log message updates

31 Mar 21:47
9296c7c
Compare
Choose a tag to compare
  • Updates RollupRepository.toString() to be used properly in log messages
  • Updated RollupAsyncProcessor to use the right record collection when resetting parent fields for full recalcs

v1.5.57 - Full Batch Recalc Chaining

27 Mar 23:10
3250766
Compare
Choose a tag to compare
  • fixes an issue raised in #414 where full batch recalculators included in the list of rollups to process would silently fail to run by introducing the concept of "cabooses" - since the rollup that starts any given async process has long been referred to as the "conductor," I wanted to continue on that concept by using the "caboose" (or set of cabooses, as the case may be) to describe rollups that can only be processed at the end of any given conductor's run.
  • added RollupLogger.ToStringObject marker interface, which in addition to reducing the complexity of the RollupLogger.getLogStringFromObject method, re-enables more granular logging in RollupEvaluator by properly printing the customized toString() method for non-matches. I had briefly removed that level of granularity from the logged messages produced with FINEST as the logging level in #425, but swapping around when and how those log messages were being produced allows this granularity without sacrificing performance (which is what #425 was trying to address to begin with)
  • added log message with DEBUG level inside RollupRepository which prints out count query strings; this now means that all queries run by RollupRepository end up getting logged