Skip to content
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

Interface to turn off all rollups and then cleanly turn them back on with full calculates #1469

Open
michaelhollander opened this issue May 6, 2024 · 2 comments

Comments

@michaelhollander
Copy link

Is your feature request related to a problem? Please describe.
DLRS is awesome! Thank you! A problem that I've encountered is that when I do mass imports of data, DLRS can interfere with the import. A few problems that I run into:

  • Locking errors
  • Too many rollups being scheduled for later execution which either leads to name collisions or just slows the system down generally
  • APEX timeouts
  • Too many SOQL query exceptions

The solution, of course, is to turn off DLRS rollups (even scheduled ones, since those still require SOQL, etc... to put each rollup on the queue) and then turn them back on after the import is over and then to run a full recalculate on any rollups that were disabled. But this can be time consuming - if you have 20 or more rollups, the time to turn each off is frustrating as is the time to turn them back on and run recalculates. And it may be true that you just want to turn off some rollups (the ones that relate to the objects that you are inserting) - if you have a custom metadata element called "DLRS_ON" and attach that as a condition to each rollup, it will only allow for ALL rollups to be turned on or off, not individual ones.

Describe the solution you'd like
My ideal solution would be a set of screen flows that provide a nice interface to deactivating multiple rollups simultaneously, reactivating them, and choosing which should have full recalculates. I imagine there is backend work to do to manage which are off and on, etc...

Describe alternatives you've considered
I know people use custom metadata to turn off all rollups by putting that into the filters, but that solution is imperfect. First, it requires the administrator to know about this "hack", which isn't obvious to everyone especially people using a cool declarative tool like DLRS. Second, it doens't solve the problem of the aftermath - rescheduling all of the recalculations. Finally, it doesn't allow for granularity. You turn off all rollups or you keep them on. You can't have an inbetween.

Additional context
Thank you for your thoughtfulness with this tool - I look forward to its continued improvement.

@aheber
Copy link
Contributor

aheber commented May 6, 2024

@michaelhollander, thank you for the thoughts.

We've talked about putting a broader "on/off" switch into the Custom Settings that DLRS uses. You could turn all rollups on or off for specific users, such as your integration/data load user. That wouldn't cover a lot of what you're recommending though.

Some considerations that come to mind first. Editing Custom Metadata to enable/disable specific rollups is generally outside the reach of a Flow because Flow can edit records but not Custom Metadata so it wouldn't be able to set the "Active" checkbox to off. That isn't a big deal though, we could always custom-code that or build bulk-actions into a list-view type of interface.

I think there is more work in figuring out the right way to recalculate the values when you turn the rollups back on. DLRS already has the idea of a Full Recalculate but we don't have a concept capable of doing multiple Full Recalculates safely through job chaining or knowing which ones can run in parallel. That can get tricky. Do you think users would be able to make those decisions themselves or would the tool need to handle predicting safe actions? It might be nice if we could recalculate all rollups for a given parent object so we only need to touch each record once, that can also have some considerations if some rollups cause larger limit usage than others. Just a lot that would go into making this a safe feature to let people use.

I think it would be cool to explore, even with a simple "we'll give you the tools but you have to wield them" kind of way. If DLRS was responsible for knowing what would and wouldn't work it might be impossible to get a feature like this shipped.

@michaelhollander
Copy link
Author

Thank you for your quick and thoughtful response.

Any improvements you can make in this area would be welcome. Even just having a master switch that allows us to turn DLRS on/off overall or for speific users would be great.

Regarding the considerations: the one about editting custom metadata is interesting - I wasn't aware of that, but it sounds like there is a way around this. I'm somewhat new to the SF world, although have a programming background so am not always aware of the limitations of flow are vs using apex, etc..

Regarding how to recalculate values - that's fascinating. I didn't think about the fact that chaining recalculates could cause a problem. Is one issue that some rollups rely on other rollups so that updating in the wrong order could cause problems? If that is the case, yes, I think to start with some documentation that explains that there can be a problem with multiple rollups running at the same time and then ask the user to set the recalculate order. You could make sensible suggestions based on the parent and child objects to show which could likely be done in parallel vs which ones have some chaining that requires parallel operations.

Based on your response, it sounds like another issue is that running multiple rollups on the same object could cause locking or at least performance issues, so being thoughtful about batching and chaining is required? It soundsl ike you have some ideas on that. I'm happy to talk this through further from a user perspective if that would be helpful.

And yes, I'm all for a "we'll give you the tools" approach, but maybe require some level of "I KNOW THIS IS DANGEROUS" acknowledgement before letting people at them :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants