i have a question, lets say I create a cursor having soql with user_mode and store cursor Id in some object and reteive the cursor Id with another user how will code behave as per the records fetch. both user has different record access. please help me understand this.
If I create a cursor today, and the data in the records get changed after I create the cursor, what data will I get when I try to get the records next day? The new updated data or the older stale data?
I think the depth size is 5 for developer edition and trial org otherwise it is unlimited , which means as per your code, if it is executed in developer org it should only process 5 batches and not 50. i'm still wondering why i would not use a batch over this.The only big difference i see the number of records i can process in a single transaction, in batch i can process 2000 records in a single transaction, but here i can have 10 fetch in a single transaction which are almost 20000 records, and yes also there is one more difference, through cursors i can go back and forth through the data. But i never ran into such scenarios, it will be great if you can have a scenario where you are going back and forth with the data with the batch like implementation of queueable.
Intresting and this one solves most of the complex problems in terms of pagination and async process
i have a question, lets say I create a cursor having soql with user_mode and store cursor Id in some object and reteive the cursor Id with another user how will code behave as per the records fetch. both user has different record access.
please help me understand this.
If I create a cursor today, and the data in the records get changed after I create the cursor, what data will I get when I try to get the records next day? The new updated data or the older stale data?
41:35 Lol. I hit the dev org storage limit when running the queueable job that creates new records :D
I think the depth size is 5 for developer edition and trial org otherwise it is unlimited , which means as per your code, if it is executed in developer org it should only process 5 batches and not 50. i'm still wondering why i would not use a batch over this.The only big difference i see the number of records i can process in a single transaction, in batch i can process 2000 records in a single transaction, but here i can have 10 fetch in a single transaction which are almost 20000 records, and yes also there is one more difference, through cursors i can go back and forth through the data. But i never ran into such scenarios, it will be great if you can have a scenario where you are going back and forth with the data with the batch like implementation of queueable.
awesome