What does “Enable Improved Caching of Org Schema” actually do?
This Critical Update sounds like a welcome change, but it's not terribly specific. What does this Critical Update actually entail? Will we still be able to sniff hidden object types using Id.getSObjectType()? Will this somehow make it impossible to leak versioned API fields (e.g. LastViewedDate to a < 28.0 class)? This sounds like a great new feature if it eliminates bugs, but the wording seems a bit vague.
apex critical-update
asked Dec 17 '18 at 20:13
sfdcfoxsfdcfox
256k11201441
add a comment |
This Critical Update sounds like a welcome change, but it's not terribly specific. What does this Critical Update actually entail? Will we still be able to sniff hidden object types using Id.getSObjectType()? Will this somehow make it impossible to leak versioned API fields (e.g. LastViewedDate to a < 28.0 class)? This sounds like a great new feature if it eliminates bugs, but the wording seems a bit vague.
apex critical-update
asked Dec 17 '18 at 20:13
sfdcfoxsfdcfox
256k11201441
Seems like to be that way by reading this -- [This update also resolves rare, intermittent cases where undocumented object types are visible in Apex describe result methods or where version-specific schema details could be improperly reused.]
– Jayant Das
Dec 17 '18 at 20:43
2
@JayantDas I'm still able to describe EmailTemp, which is undocumented, and why I asked. Apparently, it only fixes three specific Known Issues that I noticed after activation. Knowing exactly how it fixes things would be great to know.
– sfdcfox
Dec 17 '18 at 20:53
Heads up we've had to defer this critical update to Summer '19: twitter.com/ca_peterson/status/1088232403775025153
– ca_peterson
Jan 24 at 0:31
add a comment |
This Critical Update sounds like a welcome change, but it's not terribly specific. What does this Critical Update actually entail? Will we still be able to sniff hidden object types using Id.getSObjectType()? Will this somehow make it impossible to leak versioned API fields (e.g. LastViewedDate to a < 28.0 class)? This sounds like a great new feature if it eliminates bugs, but the wording seems a bit vague.
apex critical-update
asked Dec 17 '18 at 20:13
sfdcfoxsfdcfox
256k11201441
This Critical Update sounds like a welcome change, but it's not terribly specific. What does this Critical Update actually entail? Will we still be able to sniff hidden object types using Id.getSObjectType()? Will this somehow make it impossible to leak versioned API fields (e.g. LastViewedDate to a < 28.0 class)? This sounds like a great new feature if it eliminates bugs, but the wording seems a bit vague.
apex critical-update
apex critical-update
asked Dec 17 '18 at 20:13
sfdcfoxsfdcfox
256k11201441
asked Dec 17 '18 at 20:13
sfdcfoxsfdcfox
256k11201441
asked Dec 17 '18 at 20:13
sfdcfoxsfdcfox
256k11201441
asked Dec 17 '18 at 20:13
sfdcfoxsfdcfox
256k11201441
asked Dec 17 '18 at 20:13
sfdcfoxsfdcfox
256k11201441
256k11201441
Seems like to be that way by reading this -- [This update also resolves rare, intermittent cases where undocumented object types are visible in Apex describe result methods or where version-specific schema details could be improperly reused.]
– Jayant Das
Dec 17 '18 at 20:43
2
@JayantDas I'm still able to describe EmailTemp, which is undocumented, and why I asked. Apparently, it only fixes three specific Known Issues that I noticed after activation. Knowing exactly how it fixes things would be great to know.
– sfdcfox
Dec 17 '18 at 20:53
Heads up we've had to defer this critical update to Summer '19: twitter.com/ca_peterson/status/1088232403775025153
– ca_peterson
Jan 24 at 0:31
add a comment |
Seems like to be that way by reading this -- [This update also resolves rare, intermittent cases where undocumented object types are visible in Apex describe result methods or where version-specific schema details could be improperly reused.]
– Jayant Das
Dec 17 '18 at 20:43
2
@JayantDas I'm still able to describe EmailTemp, which is undocumented, and why I asked. Apparently, it only fixes three specific Known Issues that I noticed after activation. Knowing exactly how it fixes things would be great to know.
– sfdcfox
Dec 17 '18 at 20:53
Heads up we've had to defer this critical update to Summer '19: twitter.com/ca_peterson/status/1088232403775025153
– ca_peterson
Jan 24 at 0:31
Seems like to be that way by reading this -- [This update also resolves rare, intermittent cases where undocumented object types are visible in Apex describe result methods or where version-specific schema details could be improperly reused.]
– Jayant Das
Dec 17 '18 at 20:43
Seems like to be that way by reading this -- [This update also resolves rare, intermittent cases where undocumented object types are visible in Apex describe result methods or where version-specific schema details could be improperly reused.]
– Jayant Das
Dec 17 '18 at 20:43
2
2
@JayantDas I'm still able to describe EmailTemp, which is undocumented, and why I asked. Apparently, it only fixes three specific Known Issues that I noticed after activation. Knowing exactly how it fixes things would be great to know.
– sfdcfox
Dec 17 '18 at 20:53
@JayantDas I'm still able to describe EmailTemp, which is undocumented, and why I asked. Apparently, it only fixes three specific Known Issues that I noticed after activation. Knowing exactly how it fixes things would be great to know.
– sfdcfox
Dec 17 '18 at 20:53
Heads up we've had to defer this critical update to Summer '19: twitter.com/ca_peterson/status/1088232403775025153
– ca_peterson
Jan 24 at 0:31
Heads up we've had to defer this critical update to Summer '19: twitter.com/ca_peterson/status/1088232403775025153
– ca_peterson
Jan 24 at 0:31
add a comment |
2 Answers
2
active
oldest
votes
There's been a family of long-standing issues with edge cases in how the platform handles caching schema describe information under the covers. As Daniel mentioned, there are KIs that have gone unfixed where issues like initializing the describe for say, Account, at an old API version and then trying to access it with a newer one would (incorrectly) omit fields added between the old and new version (LastReferencedDate/LastViewedDate being a popular one that was impacted).
There are a number of other other ways this can manifest - if you've ever seen the ConferenceNumber type in your global describe? That's another category of issue where an internal-only SObject was accidentally made accessible through a describe being cached longer than it should have been. The mentioned EmailTemp type isn't impacted by this type of caching issue, it more simply just lacks the check the prevents it from being org visible (but it is never API editable, so you can't do anything all that interesting with it anyways) - that's a wholly different type of issue that this CRUC doesn't change.
The Apex team did work for Spring '19 to refactor some of this caching, but if you have code/customizations that rely on this incorrect behavior this change would be considered breaking (despite bringing it in line with documented behavior). Rather than surprise you with this, we put it behind a critical update to allow testing and reporting any potential issues before it's mandatory.
Really, unless you have some sort of downright insane hack this shouldn't break anything for you - and if you do have that kind of hack it's likely not working consistently anyways. With that said, this is also something Hammer testing is poor at caching due to the particulars of the schema caching it runs with, so we particularly felt the need to be safe rather than sorry here without that safety net providing as much assurance as it normally does.
If you ever had support recommend creating a class with a name starting with "AAAA_" to ensure it's loaded first when compiling? This fixes you.
The wording is a bit vague, since trying to explain the intricacies of our schema definition and caching system is quite arcane, and some gymnastics are required to be able to even describe the type of issues this fixes, particularly to customers who aren't veteran Apex developers.
If you turn this on and see issues (other than bugs being fixed), we'd love to know more.
answered Dec 18 '18 at 4:50
ca_petersonca_peterson
18.4k656107
Okay, so the LastViewedDate apparently still kills queries and throw fun exceptions like "System.SObjectException: Field Contact.LastViewedDate is inaccessible in this context". This update apparently just fixes "under the cover" bugs, and not the more "obvious" bugs, like intentionally returning a field token from a supported version to an unsupported version, right?
– sfdcfox
Dec 18 '18 at 5:33
I think I've got the gist of what class of bugs this fixes. I'm rather traditional; I avoid mixing versions as much as possible, and I try to bump up things as frequently as I can, and my tests usually catch behavior differences between versions, which explains why I've never run into these before. The wording was just vague enough that I thought it fixed a different class of issues than what was actually addressed.
– sfdcfox
Dec 18 '18 at 5:41
So, issue like this success.salesforce.com/… going to be fixed?
– Ayub
Dec 18 '18 at 6:02
@Ayub that bug should have been fixed as a versioned change in winter 19 independently of this critical update, I'll need to check when I'm at my desk why the KI status is wrong - it should show as fixed.
– ca_peterson
Dec 18 '18 at 6:54
1
@sfdcfox I wouldn't even call that a bug, passing a versioned field into an old version shouldn't work if we're versioning things right. That said, right - we didn't make changes to the apex runtime or describe types themselves, but rather to the systems we ask for details about org schema and expose to you in apex describe data. We didn't actually change the describe or token type bahvior, just the bahvior of the system that tells us which ones exist from your current viewpoint (api version, user license, etc)
– ca_peterson
Dec 18 '18 at 6:59
|
show 1 more comment
I'd checked in with Chris Peterson about this, specifically around the concern that I wouldn't be able to use Id.getSObjectType(). This critical update isn't about that altering that behavior.
Instead it is to fix known issues like Missing dependent object: Field: .LastViewedDate error occurs when Apex class with API version 28.0+ is used in VF with API version 27.0-. As you mentioned, this is where the LastViewedDate field in the describe map from and API V28.0 Apex class caused errors in a Visualforce page on v27.0 or lower that used the Apex class as it's controller.
answered Dec 18 '18 at 0:00
Daniel BallingerDaniel Ballinger
73.1k15149395
I've also reached out to Chris to help clarify this or add his own answer.
– Daniel Ballinger
Dec 18 '18 at 0:23
2
I had a different long-standing issue in mind that I thought this fixed, but it doesn't. Combining the KIs with these answers filled in the blanks.
– sfdcfox
Dec 18 '18 at 5:43
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "459"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f243905%2fwhat-does-enable-improved-caching-of-org-schema-actually-do%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
There's been a family of long-standing issues with edge cases in how the platform handles caching schema describe information under the covers. As Daniel mentioned, there are KIs that have gone unfixed where issues like initializing the describe for say, Account, at an old API version and then trying to access it with a newer one would (incorrectly) omit fields added between the old and new version (LastReferencedDate/LastViewedDate being a popular one that was impacted).
There are a number of other other ways this can manifest - if you've ever seen the ConferenceNumber type in your global describe? That's another category of issue where an internal-only SObject was accidentally made accessible through a describe being cached longer than it should have been. The mentioned EmailTemp type isn't impacted by this type of caching issue, it more simply just lacks the check the prevents it from being org visible (but it is never API editable, so you can't do anything all that interesting with it anyways) - that's a wholly different type of issue that this CRUC doesn't change.
The Apex team did work for Spring '19 to refactor some of this caching, but if you have code/customizations that rely on this incorrect behavior this change would be considered breaking (despite bringing it in line with documented behavior). Rather than surprise you with this, we put it behind a critical update to allow testing and reporting any potential issues before it's mandatory.
Really, unless you have some sort of downright insane hack this shouldn't break anything for you - and if you do have that kind of hack it's likely not working consistently anyways. With that said, this is also something Hammer testing is poor at caching due to the particulars of the schema caching it runs with, so we particularly felt the need to be safe rather than sorry here without that safety net providing as much assurance as it normally does.
If you ever had support recommend creating a class with a name starting with "AAAA_" to ensure it's loaded first when compiling? This fixes you.
The wording is a bit vague, since trying to explain the intricacies of our schema definition and caching system is quite arcane, and some gymnastics are required to be able to even describe the type of issues this fixes, particularly to customers who aren't veteran Apex developers.
If you turn this on and see issues (other than bugs being fixed), we'd love to know more.
answered Dec 18 '18 at 4:50
ca_petersonca_peterson
18.4k656107
Okay, so the LastViewedDate apparently still kills queries and throw fun exceptions like "System.SObjectException: Field Contact.LastViewedDate is inaccessible in this context". This update apparently just fixes "under the cover" bugs, and not the more "obvious" bugs, like intentionally returning a field token from a supported version to an unsupported version, right?
– sfdcfox
Dec 18 '18 at 5:33
I think I've got the gist of what class of bugs this fixes. I'm rather traditional; I avoid mixing versions as much as possible, and I try to bump up things as frequently as I can, and my tests usually catch behavior differences between versions, which explains why I've never run into these before. The wording was just vague enough that I thought it fixed a different class of issues than what was actually addressed.
– sfdcfox
Dec 18 '18 at 5:41
So, issue like this success.salesforce.com/… going to be fixed?
– Ayub
Dec 18 '18 at 6:02
@Ayub that bug should have been fixed as a versioned change in winter 19 independently of this critical update, I'll need to check when I'm at my desk why the KI status is wrong - it should show as fixed.
– ca_peterson
Dec 18 '18 at 6:54
1
@sfdcfox I wouldn't even call that a bug, passing a versioned field into an old version shouldn't work if we're versioning things right. That said, right - we didn't make changes to the apex runtime or describe types themselves, but rather to the systems we ask for details about org schema and expose to you in apex describe data. We didn't actually change the describe or token type bahvior, just the bahvior of the system that tells us which ones exist from your current viewpoint (api version, user license, etc)
– ca_peterson
Dec 18 '18 at 6:59
|
show 1 more comment
There's been a family of long-standing issues with edge cases in how the platform handles caching schema describe information under the covers. As Daniel mentioned, there are KIs that have gone unfixed where issues like initializing the describe for say, Account, at an old API version and then trying to access it with a newer one would (incorrectly) omit fields added between the old and new version (LastReferencedDate/LastViewedDate being a popular one that was impacted).
There are a number of other other ways this can manifest - if you've ever seen the ConferenceNumber type in your global describe? That's another category of issue where an internal-only SObject was accidentally made accessible through a describe being cached longer than it should have been. The mentioned EmailTemp type isn't impacted by this type of caching issue, it more simply just lacks the check the prevents it from being org visible (but it is never API editable, so you can't do anything all that interesting with it anyways) - that's a wholly different type of issue that this CRUC doesn't change.
The Apex team did work for Spring '19 to refactor some of this caching, but if you have code/customizations that rely on this incorrect behavior this change would be considered breaking (despite bringing it in line with documented behavior). Rather than surprise you with this, we put it behind a critical update to allow testing and reporting any potential issues before it's mandatory.
Really, unless you have some sort of downright insane hack this shouldn't break anything for you - and if you do have that kind of hack it's likely not working consistently anyways. With that said, this is also something Hammer testing is poor at caching due to the particulars of the schema caching it runs with, so we particularly felt the need to be safe rather than sorry here without that safety net providing as much assurance as it normally does.
If you ever had support recommend creating a class with a name starting with "AAAA_" to ensure it's loaded first when compiling? This fixes you.
The wording is a bit vague, since trying to explain the intricacies of our schema definition and caching system is quite arcane, and some gymnastics are required to be able to even describe the type of issues this fixes, particularly to customers who aren't veteran Apex developers.
If you turn this on and see issues (other than bugs being fixed), we'd love to know more.
answered Dec 18 '18 at 4:50
ca_petersonca_peterson
18.4k656107
Okay, so the LastViewedDate apparently still kills queries and throw fun exceptions like "System.SObjectException: Field Contact.LastViewedDate is inaccessible in this context". This update apparently just fixes "under the cover" bugs, and not the more "obvious" bugs, like intentionally returning a field token from a supported version to an unsupported version, right?
– sfdcfox
Dec 18 '18 at 5:33
I think I've got the gist of what class of bugs this fixes. I'm rather traditional; I avoid mixing versions as much as possible, and I try to bump up things as frequently as I can, and my tests usually catch behavior differences between versions, which explains why I've never run into these before. The wording was just vague enough that I thought it fixed a different class of issues than what was actually addressed.
– sfdcfox
Dec 18 '18 at 5:41
So, issue like this success.salesforce.com/… going to be fixed?
– Ayub
Dec 18 '18 at 6:02
@Ayub that bug should have been fixed as a versioned change in winter 19 independently of this critical update, I'll need to check when I'm at my desk why the KI status is wrong - it should show as fixed.
– ca_peterson
Dec 18 '18 at 6:54
1
@sfdcfox I wouldn't even call that a bug, passing a versioned field into an old version shouldn't work if we're versioning things right. That said, right - we didn't make changes to the apex runtime or describe types themselves, but rather to the systems we ask for details about org schema and expose to you in apex describe data. We didn't actually change the describe or token type bahvior, just the bahvior of the system that tells us which ones exist from your current viewpoint (api version, user license, etc)
– ca_peterson
Dec 18 '18 at 6:59
|
show 1 more comment
There's been a family of long-standing issues with edge cases in how the platform handles caching schema describe information under the covers. As Daniel mentioned, there are KIs that have gone unfixed where issues like initializing the describe for say, Account, at an old API version and then trying to access it with a newer one would (incorrectly) omit fields added between the old and new version (LastReferencedDate/LastViewedDate being a popular one that was impacted).
There are a number of other other ways this can manifest - if you've ever seen the ConferenceNumber type in your global describe? That's another category of issue where an internal-only SObject was accidentally made accessible through a describe being cached longer than it should have been. The mentioned EmailTemp type isn't impacted by this type of caching issue, it more simply just lacks the check the prevents it from being org visible (but it is never API editable, so you can't do anything all that interesting with it anyways) - that's a wholly different type of issue that this CRUC doesn't change.
The Apex team did work for Spring '19 to refactor some of this caching, but if you have code/customizations that rely on this incorrect behavior this change would be considered breaking (despite bringing it in line with documented behavior). Rather than surprise you with this, we put it behind a critical update to allow testing and reporting any potential issues before it's mandatory.
Really, unless you have some sort of downright insane hack this shouldn't break anything for you - and if you do have that kind of hack it's likely not working consistently anyways. With that said, this is also something Hammer testing is poor at caching due to the particulars of the schema caching it runs with, so we particularly felt the need to be safe rather than sorry here without that safety net providing as much assurance as it normally does.
If you ever had support recommend creating a class with a name starting with "AAAA_" to ensure it's loaded first when compiling? This fixes you.
The wording is a bit vague, since trying to explain the intricacies of our schema definition and caching system is quite arcane, and some gymnastics are required to be able to even describe the type of issues this fixes, particularly to customers who aren't veteran Apex developers.
If you turn this on and see issues (other than bugs being fixed), we'd love to know more.
answered Dec 18 '18 at 4:50
ca_petersonca_peterson
18.4k656107
There's been a family of long-standing issues with edge cases in how the platform handles caching schema describe information under the covers. As Daniel mentioned, there are KIs that have gone unfixed where issues like initializing the describe for say, Account, at an old API version and then trying to access it with a newer one would (incorrectly) omit fields added between the old and new version (LastReferencedDate/LastViewedDate being a popular one that was impacted).
There are a number of other other ways this can manifest - if you've ever seen the ConferenceNumber type in your global describe? That's another category of issue where an internal-only SObject was accidentally made accessible through a describe being cached longer than it should have been. The mentioned EmailTemp type isn't impacted by this type of caching issue, it more simply just lacks the check the prevents it from being org visible (but it is never API editable, so you can't do anything all that interesting with it anyways) - that's a wholly different type of issue that this CRUC doesn't change.
The Apex team did work for Spring '19 to refactor some of this caching, but if you have code/customizations that rely on this incorrect behavior this change would be considered breaking (despite bringing it in line with documented behavior). Rather than surprise you with this, we put it behind a critical update to allow testing and reporting any potential issues before it's mandatory.
Really, unless you have some sort of downright insane hack this shouldn't break anything for you - and if you do have that kind of hack it's likely not working consistently anyways. With that said, this is also something Hammer testing is poor at caching due to the particulars of the schema caching it runs with, so we particularly felt the need to be safe rather than sorry here without that safety net providing as much assurance as it normally does.
If you ever had support recommend creating a class with a name starting with "AAAA_" to ensure it's loaded first when compiling? This fixes you.
The wording is a bit vague, since trying to explain the intricacies of our schema definition and caching system is quite arcane, and some gymnastics are required to be able to even describe the type of issues this fixes, particularly to customers who aren't veteran Apex developers.
If you turn this on and see issues (other than bugs being fixed), we'd love to know more.
answered Dec 18 '18 at 4:50
ca_petersonca_peterson
18.4k656107
answered Dec 18 '18 at 4:50
ca_petersonca_peterson
18.4k656107
answered Dec 18 '18 at 4:50
ca_petersonca_peterson
18.4k656107
answered Dec 18 '18 at 4:50
ca_petersonca_peterson
18.4k656107
18.4k656107
Okay, so the LastViewedDate apparently still kills queries and throw fun exceptions like "System.SObjectException: Field Contact.LastViewedDate is inaccessible in this context". This update apparently just fixes "under the cover" bugs, and not the more "obvious" bugs, like intentionally returning a field token from a supported version to an unsupported version, right?
– sfdcfox
Dec 18 '18 at 5:33
I think I've got the gist of what class of bugs this fixes. I'm rather traditional; I avoid mixing versions as much as possible, and I try to bump up things as frequently as I can, and my tests usually catch behavior differences between versions, which explains why I've never run into these before. The wording was just vague enough that I thought it fixed a different class of issues than what was actually addressed.
– sfdcfox
Dec 18 '18 at 5:41
So, issue like this success.salesforce.com/… going to be fixed?
– Ayub
Dec 18 '18 at 6:02
@Ayub that bug should have been fixed as a versioned change in winter 19 independently of this critical update, I'll need to check when I'm at my desk why the KI status is wrong - it should show as fixed.
– ca_peterson
Dec 18 '18 at 6:54
1
@sfdcfox I wouldn't even call that a bug, passing a versioned field into an old version shouldn't work if we're versioning things right. That said, right - we didn't make changes to the apex runtime or describe types themselves, but rather to the systems we ask for details about org schema and expose to you in apex describe data. We didn't actually change the describe or token type bahvior, just the bahvior of the system that tells us which ones exist from your current viewpoint (api version, user license, etc)
– ca_peterson
Dec 18 '18 at 6:59
|
show 1 more comment
Okay, so the LastViewedDate apparently still kills queries and throw fun exceptions like "System.SObjectException: Field Contact.LastViewedDate is inaccessible in this context". This update apparently just fixes "under the cover" bugs, and not the more "obvious" bugs, like intentionally returning a field token from a supported version to an unsupported version, right?
– sfdcfox
Dec 18 '18 at 5:33
I think I've got the gist of what class of bugs this fixes. I'm rather traditional; I avoid mixing versions as much as possible, and I try to bump up things as frequently as I can, and my tests usually catch behavior differences between versions, which explains why I've never run into these before. The wording was just vague enough that I thought it fixed a different class of issues than what was actually addressed.
– sfdcfox
Dec 18 '18 at 5:41
So, issue like this success.salesforce.com/… going to be fixed?
– Ayub
Dec 18 '18 at 6:02
@Ayub that bug should have been fixed as a versioned change in winter 19 independently of this critical update, I'll need to check when I'm at my desk why the KI status is wrong - it should show as fixed.
– ca_peterson
Dec 18 '18 at 6:54
1
@sfdcfox I wouldn't even call that a bug, passing a versioned field into an old version shouldn't work if we're versioning things right. That said, right - we didn't make changes to the apex runtime or describe types themselves, but rather to the systems we ask for details about org schema and expose to you in apex describe data. We didn't actually change the describe or token type bahvior, just the bahvior of the system that tells us which ones exist from your current viewpoint (api version, user license, etc)
– ca_peterson
Dec 18 '18 at 6:59
Okay, so the LastViewedDate apparently still kills queries and throw fun exceptions like "System.SObjectException: Field Contact.LastViewedDate is inaccessible in this context". This update apparently just fixes "under the cover" bugs, and not the more "obvious" bugs, like intentionally returning a field token from a supported version to an unsupported version, right?
– sfdcfox
Dec 18 '18 at 5:33
Okay, so the LastViewedDate apparently still kills queries and throw fun exceptions like "System.SObjectException: Field Contact.LastViewedDate is inaccessible in this context". This update apparently just fixes "under the cover" bugs, and not the more "obvious" bugs, like intentionally returning a field token from a supported version to an unsupported version, right?
– sfdcfox
Dec 18 '18 at 5:33
I think I've got the gist of what class of bugs this fixes. I'm rather traditional; I avoid mixing versions as much as possible, and I try to bump up things as frequently as I can, and my tests usually catch behavior differences between versions, which explains why I've never run into these before. The wording was just vague enough that I thought it fixed a different class of issues than what was actually addressed.
– sfdcfox
Dec 18 '18 at 5:41
I think I've got the gist of what class of bugs this fixes. I'm rather traditional; I avoid mixing versions as much as possible, and I try to bump up things as frequently as I can, and my tests usually catch behavior differences between versions, which explains why I've never run into these before. The wording was just vague enough that I thought it fixed a different class of issues than what was actually addressed.
– sfdcfox
Dec 18 '18 at 5:41
So, issue like this success.salesforce.com/… going to be fixed?
– Ayub
Dec 18 '18 at 6:02
So, issue like this success.salesforce.com/… going to be fixed?
– Ayub
Dec 18 '18 at 6:02
@Ayub that bug should have been fixed as a versioned change in winter 19 independently of this critical update, I'll need to check when I'm at my desk why the KI status is wrong - it should show as fixed.
– ca_peterson
Dec 18 '18 at 6:54
@Ayub that bug should have been fixed as a versioned change in winter 19 independently of this critical update, I'll need to check when I'm at my desk why the KI status is wrong - it should show as fixed.
– ca_peterson
Dec 18 '18 at 6:54
1
1
@sfdcfox I wouldn't even call that a bug, passing a versioned field into an old version shouldn't work if we're versioning things right. That said, right - we didn't make changes to the apex runtime or describe types themselves, but rather to the systems we ask for details about org schema and expose to you in apex describe data. We didn't actually change the describe or token type bahvior, just the bahvior of the system that tells us which ones exist from your current viewpoint (api version, user license, etc)
– ca_peterson
Dec 18 '18 at 6:59
@sfdcfox I wouldn't even call that a bug, passing a versioned field into an old version shouldn't work if we're versioning things right. That said, right - we didn't make changes to the apex runtime or describe types themselves, but rather to the systems we ask for details about org schema and expose to you in apex describe data. We didn't actually change the describe or token type bahvior, just the bahvior of the system that tells us which ones exist from your current viewpoint (api version, user license, etc)
– ca_peterson
Dec 18 '18 at 6:59
|
show 1 more comment
I'd checked in with Chris Peterson about this, specifically around the concern that I wouldn't be able to use Id.getSObjectType(). This critical update isn't about that altering that behavior.
Instead it is to fix known issues like Missing dependent object: Field: .LastViewedDate error occurs when Apex class with API version 28.0+ is used in VF with API version 27.0-. As you mentioned, this is where the LastViewedDate field in the describe map from and API V28.0 Apex class caused errors in a Visualforce page on v27.0 or lower that used the Apex class as it's controller.
answered Dec 18 '18 at 0:00
Daniel BallingerDaniel Ballinger
73.1k15149395
I've also reached out to Chris to help clarify this or add his own answer.
– Daniel Ballinger
Dec 18 '18 at 0:23
2
I had a different long-standing issue in mind that I thought this fixed, but it doesn't. Combining the KIs with these answers filled in the blanks.
– sfdcfox
Dec 18 '18 at 5:43
add a comment |
I'd checked in with Chris Peterson about this, specifically around the concern that I wouldn't be able to use Id.getSObjectType(). This critical update isn't about that altering that behavior.
Instead it is to fix known issues like Missing dependent object: Field: .LastViewedDate error occurs when Apex class with API version 28.0+ is used in VF with API version 27.0-. As you mentioned, this is where the LastViewedDate field in the describe map from and API V28.0 Apex class caused errors in a Visualforce page on v27.0 or lower that used the Apex class as it's controller.
answered Dec 18 '18 at 0:00
Daniel BallingerDaniel Ballinger
73.1k15149395
I've also reached out to Chris to help clarify this or add his own answer.
– Daniel Ballinger
Dec 18 '18 at 0:23
2
I had a different long-standing issue in mind that I thought this fixed, but it doesn't. Combining the KIs with these answers filled in the blanks.
– sfdcfox
Dec 18 '18 at 5:43
add a comment |
I'd checked in with Chris Peterson about this, specifically around the concern that I wouldn't be able to use Id.getSObjectType(). This critical update isn't about that altering that behavior.
Instead it is to fix known issues like Missing dependent object: Field: .LastViewedDate error occurs when Apex class with API version 28.0+ is used in VF with API version 27.0-. As you mentioned, this is where the LastViewedDate field in the describe map from and API V28.0 Apex class caused errors in a Visualforce page on v27.0 or lower that used the Apex class as it's controller.
answered Dec 18 '18 at 0:00
Daniel BallingerDaniel Ballinger
73.1k15149395
I'd checked in with Chris Peterson about this, specifically around the concern that I wouldn't be able to use Id.getSObjectType(). This critical update isn't about that altering that behavior.
Instead it is to fix known issues like Missing dependent object: Field: .LastViewedDate error occurs when Apex class with API version 28.0+ is used in VF with API version 27.0-. As you mentioned, this is where the LastViewedDate field in the describe map from and API V28.0 Apex class caused errors in a Visualforce page on v27.0 or lower that used the Apex class as it's controller.
answered Dec 18 '18 at 0:00
Daniel BallingerDaniel Ballinger
73.1k15149395
answered Dec 18 '18 at 0:00
Daniel BallingerDaniel Ballinger
73.1k15149395
answered Dec 18 '18 at 0:00
Daniel BallingerDaniel Ballinger
73.1k15149395
answered Dec 18 '18 at 0:00
Daniel BallingerDaniel Ballinger
73.1k15149395
73.1k15149395
I've also reached out to Chris to help clarify this or add his own answer.
– Daniel Ballinger
Dec 18 '18 at 0:23
2
I had a different long-standing issue in mind that I thought this fixed, but it doesn't. Combining the KIs with these answers filled in the blanks.
– sfdcfox
Dec 18 '18 at 5:43
add a comment |
I've also reached out to Chris to help clarify this or add his own answer.
– Daniel Ballinger
Dec 18 '18 at 0:23
2
I had a different long-standing issue in mind that I thought this fixed, but it doesn't. Combining the KIs with these answers filled in the blanks.
– sfdcfox
Dec 18 '18 at 5:43
I've also reached out to Chris to help clarify this or add his own answer.
– Daniel Ballinger
Dec 18 '18 at 0:23
I've also reached out to Chris to help clarify this or add his own answer.
– Daniel Ballinger
Dec 18 '18 at 0:23
2
2
I had a different long-standing issue in mind that I thought this fixed, but it doesn't. Combining the KIs with these answers filled in the blanks.
– sfdcfox
Dec 18 '18 at 5:43
I had a different long-standing issue in mind that I thought this fixed, but it doesn't. Combining the KIs with these answers filled in the blanks.
– sfdcfox
Dec 18 '18 at 5:43
add a comment |
Thanks for contributing an answer to Salesforce Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f243905%2fwhat-does-enable-improved-caching-of-org-schema-actually-do%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Seems like to be that way by reading this -- [This update also resolves rare, intermittent cases where undocumented object types are visible in Apex describe result methods or where version-specific schema details could be improperly reused.]
– Jayant Das
Dec 17 '18 at 20:43
2
@JayantDas I'm still able to describe EmailTemp, which is undocumented, and why I asked. Apparently, it only fixes three specific Known Issues that I noticed after activation. Knowing exactly how it fixes things would be great to know.
– sfdcfox
Dec 17 '18 at 20:53
Heads up we've had to defer this critical update to Summer '19: twitter.com/ca_peterson/status/1088232403775025153
– ca_peterson
Jan 24 at 0:31