Apex Code Development You need to sign in to do that
Don't have an account?
Vonvee ID token pattern
The unique tokens that Salesforce gives to items -- can someone confirm if newer items will always have a greaterThan relationship than previous items? I've noticed this pattern for months and have discovered internally we have some programming against it.
Example: select max(LeadID) from Lead group by Phone ' --> The newest record created by phone number
Yes I know doing it by date in the query would be better, but does the above logic always hold true as it seems to for the past year+ that we've had our system? I'm trying to figure out if I have to refactor a bunch of custom code if the answer is no.
Its mostly true, however there are some edge cases that will make it not true, to some degree it dpends on your definition of "newer". the Ids are sequential (with possible gaps), but they are assigned to potential rows at the start of the transaction, concurrent transactions can end up commiting in a different sequence to their start order (due to lock contention etc). If by newer you mean the createdDate timestamp, then that timestamp is assigned at a different point in the process to the Ids, so they can end up with a different ordering, Whether this is an issue for you will really depend on what "newest" means to you
All Answers
Its mostly true, however there are some edge cases that will make it not true, to some degree it dpends on your definition of "newer". the Ids are sequential (with possible gaps), but they are assigned to potential rows at the start of the transaction, concurrent transactions can end up commiting in a different sequence to their start order (due to lock contention etc). If by newer you mean the createdDate timestamp, then that timestamp is assigned at a different point in the process to the Ids, so they can end up with a different ordering, Whether this is an issue for you will really depend on what "newest" means to you
And none of this is guaranteed to not change, so using the timestamp would be better from that point of view.
Understood; thanks for the confirmation. In short, 99%+ of the time it seems that (pending some major change in current SF logic), the logic for our normal business needs will hold up.
My understanding of your comment shows possible discrepancy between records coming in at near simultaneous "real time" loads; I get that and understand where it could go awry based on load size/type/transaction lock etc.
But in the case of "Today" versus "Yesterday" (or really now vs 1 hour ago), it's going to be a decently solid assumption. Poor "code standard", but not something that currently will cause us great pains or data corruption.
Thanks Simon.
Yup, you've got it.