3

Why can we use non-primitive data types in Queueable and not in Future methods when both are async processes?

The reason that salesforce has documented is - '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.'

But this is also true for Queueable as that is also async process then why are we allowing non-primitive in queueable?

0

2 Answers 2

5

Future methods were a very early async mechanism and as such are less capable than Batchables, Queueables and Schedulables.

In terms of the reason stated by Salesforce for not supporting SObjects and similar, as per the documentation you have quoted, I personally view this as likely not the real rationale.

Back when future methods were introduced, I suspect this limitation was more to ensure that the state for the future method call that had to be stored in the database (the serialized form of the parameter data) was kept small, so as to not take up too much database storage.

That this doesn't apply to Queueables is, in my opinion, simply because time has moved on and Salesforce are happier to store more data in the async state tables within the platform.

As per the documentation, queueables allow complex parameters and state:

Using non-primitive types: Your queueable class can contain member variables of non-primitive data types, such as sObjects or custom Apex types. Those objects can be accessed when the job executes.

NB: There are certain limitations on what can be used as state for your queueable object's state; if the type you want to use does not support JSON serialisation, you cannot use it as non-volatile properties in your queueable. This applies to certain Salesforce API objects.

So, in answer to your question (and as commented by @DerekF) this is the way it is "because Salesforce says so". But you can read between the lines and conclude it is likely because the platform infrastructure has improved and they are better able to support more data-hungry async processes.

2
  • 1
    but why does queueable allow this? The main point of the question that I see is queueable is still subject to the "data can change before the async execution" bit that was the stated reason for not allowing this in @future, so why is it ok in Queueable?. Unfortunately, I think the answer to that is "because Salesforce says so, that's why".
    – Derek F
    Jan 23, 2023 at 12:23
  • @DerekF Ah, I see what you mean - I didn't read it that way at first - and I'll update my answer accordingly.
    – Phil W
    Jan 23, 2023 at 13:01
-3

Methods with the future annotation must be static methods, and can only return a void type. The specified parameters must be primitive data types, arrays of primitive data types, or collections of primitive data types. Methods with the future annotation cannot take sObjects or objects as arguments. https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_invoking_future_methods.htm

1
  • I've downvoted this answer because it's simply a quote from documentation, and OP seems to be already familiar with the documentation (OP quotes the paragraph directly below the one you quoted). This also doesn't answer the question being asked (why can queueable take non-primitive arguments when SObjects can still change before execution, just like the case for @future?)
    – Derek F
    Jan 23, 2023 at 12:20

You must log in to answer this question.

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