3

I am having a small doubt, and want to have some inputs on that.

For future methods, we are not allowed to have sObjects as method params/arguments. and the reason in documentation is stated as below:

The reason why sObjects can’t be passed as arguments to future methods is because the sObject might change between the time you call the method and the time it executes.

However, we are having same feature in queueable. So does that guarantees data integrity?

If yes, how that ensures data is not overridden.

If no, why it is not extended with future only(instead of new framework).

Thanks in advance!

Improve this question

2 Answers 2

Reset to default
1

Queueable is a completely different framework from future methods, and it gives a lot of benefits over it. It was probably easier and safer for salesforce to create a new framework/interface, than the modify the existing @future implementation without breaking existing apex code.

Also, it's likely that the reason why future methods can't take sobjects was true at the time of writing the documentation, but obviously no longer accurate as another framework (queueable) is able to handle sobjects.

Long story short, it's probably due to shortcomings of the @future framework + innacurate/outdated documentation.

Improve this answer
1
  • but still with old logic, there is still possibility for object field overwrite. So that's the risk delegated to the end user?
    – Ysr Shk
    Commented Oct 23, 2019 at 11:26
1

To add to the already good answer - There's no documentation stating "why" there's no risk of data integrity within the queueable framework. However, I think it can be assumed (based on the info available and the fact that it's a different framework) that queueable is able to pull the sObject before it executes (as opposed to being limited to only using the instance of the object when it was actually passed) and eliminate any issue where the object might have changed by the time it's actually executing.

https://trailhead.salesforce.com/en/content/learn/modules/asynchronous_apex/async_apex_queueable

enter image description here

Improve this answer
4
  • hmm.. I thought SFDC serializes the argument(s) passed to the Queueable's constructor and hence the value made available to the queueable object is the one known at time of System.enqueueJob(new MyQueueable(mySobject))
    – cropredy
    Commented Oct 24, 2019 at 1:14
  • Thanks for the answer, this is closest to the answer.I will do one POC to check whether it pulls updated copy or old copy with conflict.
    – Ysr Shk
    Commented Oct 24, 2019 at 7:52
  • I'd be interested in your results @YsrShk
    – Kris Goncalves
    Commented Nov 1, 2019 at 13:59
  • @YsrShk Did you find anything good by any chance?
    – Kamal Thakur
    Commented Jul 4, 2022 at 7:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .