v1.5.27 - Namespaced Package Release

• Adds a namespaced version of Apex Rollup (using the please namespace) for OEM/ISV/etc ... usage as per #359 . The source code for the namespaced version is exactly the same as the unlocked default namespace version of the package; the usage is the same with these key differences (also outlined in the namespaced package's README):

Namespaced Package Version specific behavior:

• Flows that don't take advantage of the CMDT-based invocable action need to fully qualify the namespace for all namespaced fields. As an example a flow using a custom object called Child__c in the please__ namespace with a custom field called Text__c:
  • would have the Child Object be specified as please__Child__c
  • would have the Rollup Object Calc Field be specified as please__Text__c
• Additionally, for both Flows and CMDT-driven rollups:
  • all Calc Item Where Clauses using namespaced fields need to have the namespace specified
  • same goes for any Grandparent Relationship Field Paths, as well as for any One To Many Grandparent Fields
• Just for the base Rollup invocable, the following also applies:
  • namespaced fields used as the Ultimate Parent need to have the namespace be fully qualified
  • namespaced fields used in the Order By field need to have the namespace be fully qualified

v1.5.26 - Is Full Record Set bugfix

• Fixes #370 by properly accounting for all records being present when Is Full Record Set flag is used for SUM/COUNT-based rollups

v1.5.25 - Logging Infra Improvements

• simplified logging setup/teardown to improve CPU performance while using multiple loggers
• removed some unformatted serializations calls that were being used with Invocables, possibly blowing the heap when used in conjunction with scheduled flows with large record collection sizes (see #368 for more information)
• started work on #363 with the above improvements - due to the mixed static usage of RollupLogger, I've been approaching the changes (necessary to update logging to active when a Rollup Control record other than the org default is used) slowly in order to ensure I'm satisfied with the code quality, performance, and consistency prior to fully committing to this approach.

v1.5.24 - The Solo Admin Special

• Further optimizations for full recalc rollup code paths by removing an intermediate inner class
• Fixes issue reported by @solo-1234 where re-submitting a full recalc job for CMDT would improperly format the Rollup Order By CMDT records
• Fixes issue reported by @solo-1234 where audit fields were causing RollupCalcItemReplacer to error out

v1.5.23 - Parent Reset Processor Fix

• Fixes issue reported by @solo-1234 where sometimes a bulk full recalc through the parent reset button or app would improperly reset some parent-level fields

v1.5.22 - Multicurrency Formula Field Conversion

• Fixes an issue reported by @kd280z where multicurrency rollups can fail if the child item rollup field is a currency formula field

V1.5.21 - Namespaced Package Added

• Doc updates which were missed as part of @jongpie feedback from v1.5.20
• Adds namespaced package version support for managed packages and unlocked packages with namespaces to be able to use Apex Rollup as per the discussion in #359
• Fixes #360 by adding Custom Setting override directly on Rollup__mdt
• Fixes issue reported by Kaushal Gautam where future methods weren't accounted for when considering when Apex Rollup was already async
• Fixes a bug reported by Katherine West where some full recalcs with many Calc Item Where Clauses had issues getting their where clauses parsed (potentially also reported by @solo-1234)
• Thanks to Kaushal Gautam (again!) for suggesting this new functionality: added ability to skip updating parents during full recalcs/full recalc updates when RollupControl__mdt.ShouldSkipResettingParentFields__c is set to true (defaults to false on the Org Default record)
• Added in clearer log messages when Apex Rollup is disabled:
  • no-op, exiting early to avoid burning async job when there are no configured rollups
  • RollupControl__mdt.ShouldAbortRun__c set to true, exiting early when ... Should Abort Run on the given Rollup Control record is set to true
  • RollupSettings__c.IsEnabled__c is false, exiting early when the Rollup Settings Custom Setting isn't enabled and the new override isn't enabled (see #360)

v1.5.20 - Optimizations All Around

• Fixes #329 (probably) by patching a situation where RollupRelationshipFieldFinder didn't always include the CurrencyIsoCode in queried parent records
• Additionally, spent the past month(!) debugging an issue found by Katherine West while upgrading versions (thanks to her own tests). While poring through debug logs, a few obvious places where optimizations could be put into place began to show themselves:
  • there were several code paths where calls to RollupControl__mdt.getInstance() was being invoked multiple times to re-load the ORG_DEFAULT rollup control record. I had previously assumed that these calls were cached internally, but in examining the logs a non-trivial amount of time was being used in each instance. The org default rollup control now gets cached properly
  • RollupAsyncProcessor.retrieveAdditionalCalcItems received several rounds' worth of improvements, including (but not limited to) the proper caching of pre-retrieved additional items
  • When the .valueOf() method originally came out for enums, I was excited to get rid of a cached map for the Rollup operation enums, but (similar to getInstance() for CMDT records, the performance of .valueOf() is pretty bad and doesn't get cached between calls. Reverting to the cached map in Rollup will help save time in the long run!
  • RollupEvaluator now caches query fields per query instead of having to explicitly regenerate them each time
  • RollupQueryBuilder (similar to the point above) does a lot of work to sanitize queries; this really benefitted from adding a caching layer for the where clause parsing
  • RollupLogger is no longer an instance of Rollup itself. This was a bit of a hack, previously, to easily allow RollupLogger to access the Org Default rollup control CMDT record, but while investigating the .valueOf() performance change above, I could also see the performance hit associated with this particular class inheritance
  • There were some code paths in Rollup (on the synchronous side) that were unnecessarily wasteful. One of the biggest offenders here was a piece of code that was always run for full recalcs, even though it was only really applicable for merges. This has now been cleaned up and properly guarded for, as well as a piece of code that sometimes unnecessarily serialized and deserialized the Rollup__mdt records even if they didn't use RollupOrderBy__mdt children
• Added an inner class, Rollup.LimitTester which has nicely prettified the reason any given rollup has for starting to time out. This used to be difficult to find information, even in logs set to FINEST; now it just gets nicely printed out
• Updated the RollupNebulaLoggerAdapter and corresponding plugin to clean up the produced stacktraces (by omitting the rollup logger classes that initiate the stacktrace), and set Apex Rollup as the Scenario. Big thanks to @jongpie for his work in Nebula Logger's latest release for adding in this functionality for me!
• Updated documentation surrounding the usage of RollupOrderBy__mdt and the corresponding Flow fields for those records to properly denote their usage with MOST and rollup operations that use a Limit Amount
• Updated Calc Item references to use Child Object notation; updated Lookup Object references to use Parent Object notation as suggested by @solo-1234

V1.5.19 - ALL, NONE, SOME Rollup operations

• Adds support for ALL, NONE, and SOME rollup operations. These use the Calc Item Where Clause to rollup to checkbox/text/number-based fields the values true or false (for checkbox/text-based fields) or 1 or 0 (for number-based fields) respectively
• Fixed a parsing issue with deeply nested conditionals in Calc Item Where Clauses that was awkwardly patched in #352
• Made order by statement unique-ify fields (for full recalc rollups, this would occasionally have produced weird SOQL order by statements like ORDER BY AccountId, AccountId which wasn't ideal
• Switching up how full recalculator rollups get re-enqueued to try to diagnose an issue reported by Katherine West

v1.5.18 - Deeply Nested Conditional Bugfix

• fixes an issue reported by @solo-1234 where full recalcs with a large number of calc item where clauses could cause RollupEvaluator parsing errors during full recalcs