-
Notifications
You must be signed in to change notification settings - Fork 238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Known ordering for RollupCalculateJob records #518
Comments
Another resource suggests that there is no guarantee of query result order without the inclusion of an |
Great idea, thanks for sharing! 👍 Marked as enhancement. |
My pleasure, thank you for your work on the project @afawcett! Do you want me to submit a PR with the change? |
@renatoliveira Yes please! 👍 |
@afawcett I think you meant that to @rogeramitchell ? 😆 |
;-) I did, thanks @renatoliveira 👍 |
Yeah thats an issue with the way the CI works in pull requests, don't worry. I'll have a look at your PR now, thanks for the submission! 👍 |
This looks great, just merged. I will get it out in the next release. I will look to carve out some person time for some popular fixes/enhancements and include your work in this. Thanks again! 👍 |
Fixed in v2.10 |
Hey there, I'm a huge fan of the tool and recommend it to anyone that needs rollups (virtually everyone).
I think there might be a feature missing to ensure there is a known order of records when using the "Calculate" or "Schedule Calculate" feature. It appears that
RollupCalculateJob
is getting the query locator fromRollupService.masterRecordsAsQueryLocator
, though I do not see where this is implementing anORDER BY
clause.If the user were to start a calculation for a rollup, it does not seem that the user should need to wait until that calculation finishes to begin the next rollup (provided the same parent object exists).
If the query returned from
RollupService.masterRecordsAsQueryLocator
were to use anORDER BY
clause as part of the query string, the order would be predictable, and thus the rollups could be staggered to start by a few minutes.I do not think the below solves for this, but figured I'd include it (in the event that it does)
https://releasenotes.docs.salesforce.com/en-us/summer15/release-notes/rn_apex_maps_and_sets_iteration_order.htm
The text was updated successfully, but these errors were encountered: