You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This also exposed another - even more wild - issue with full recalculations for hierarchical rollups, which was solved by some internal state tracking for the query strings produced for full recalculation rollups when the underlying child item type is the same.
Warning - long, potentially disinteresting architectural notes follow: the above produced a number of excellent optimizations for full recalc rollups that don't end up making use of RollupFullBatchRecalculator, since by default Apex Rollup will prefer to use queueables thanks to their excellent async speed - now, queries produced through full recalculations have two additional layers of caching to prevent duplicate (and unnecessary) queries when the children items are the same between 2 or more enqueued rollups. This involved the promotion of RollupAsyncProcessor.FullRecalcProcessor to an outer class, RollupFullRecalcProcessor and a promotion in visibility of RollupAsyncProcessor.QueueableProcessor from private to public. Since the subclasses of what was previously the FullRecalcProcessor were already extending from an inner class of RollupAsyncProcessor, this feels like a bigger win anyway since now the only place the inner class for RollupAsyncProcessor is being referenced comes in the abstract class definition for RollupFullRecalcProcessor
Cleaned up a number of duplicated variables in RollupRelationshipFieldFinderTests - now that the discrete list of both parent and child query fields are passed to this object, it was easier to consolidate (for the purpose of these tests) the Set<String> being used for parent/child fields. This cleanup exposed a few other places in the codebase where Set usage could be consolidated
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
RollupFullBatchRecalculator
, since by default Apex Rollup will prefer to use queueables thanks to their excellent async speed - now, queries produced through full recalculations have two additional layers of caching to prevent duplicate (and unnecessary) queries when the children items are the same between 2 or more enqueued rollups. This involved the promotion ofRollupAsyncProcessor.FullRecalcProcessor
to an outer class,RollupFullRecalcProcessor
and a promotion in visibility ofRollupAsyncProcessor.QueueableProcessor
from private to public. Since the subclasses of what was previously theFullRecalcProcessor
were already extending from an inner class ofRollupAsyncProcessor
, this feels like a bigger win anyway since now the only place the inner class forRollupAsyncProcessor
is being referenced comes in the abstract class definition forRollupFullRecalcProcessor
RollupRelationshipFieldFinderTests
- now that the discrete list of both parent and child query fields are passed to this object, it was easier to consolidate (for the purpose of these tests) theSet<String>
being used for parent/child fields. This cleanup exposed a few other places in the codebase where Set usage could be consolidatedThis discussion was created from the release v1.5.7 - Hierarchy Rollup Bugfixes.
Beta Was this translation helpful? Give feedback.
All reactions