Timeline for Deserialize hits memory limit
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 18, 2020 at 17:35 | vote | accept | jonathanwiesel | ||
| Jan 10, 2019 at 9:38 | comment | added | jonathanwiesel |
I'm aware that using different names in the class (jsonString.replaceAll('customfield__c', 'customfield_X)) could work but could that could hit again the Regex too complicated error? Maybe I'm wrong since it's not a regex but a plain string, yet I'm concerned on the CPU limit while replacing 50 custom fields in a 2MB string
|
|
| Jan 10, 2019 at 9:27 | comment | added | jonathanwiesel |
This seems like a great solution, in fact I marked as the correct answer until I figured out that if custom fields are included in the JSON they cannot be added to the serialization class because an attribute name with double underscores will cause an Invalid character in identifier: customfield__c error.
|
|
| Jan 10, 2019 at 9:15 | vote | accept | jonathanwiesel | ||
| Jan 10, 2019 at 9:24 | |||||
| Jan 9, 2019 at 21:33 | comment | added | Derek F |
Somehow, I didn't expect this to work (given that serialized SObjects contain extra data, i.e. the attributes attribute). However, copy/pasting the JSON from the question, and your deserialization classes, it all worked without a hitch. After mulling it over a bit, I suppose I shouldn't have been surprised. The only gotcha here is that this won't work with JSON.deserializeStrict(). +1
|
|
| Jan 9, 2019 at 20:59 | history | edited | Jayant Das | CC BY-SA 4.0 |
added 1 character in body
|
| Jan 9, 2019 at 20:57 | comment | added | Jayant Das | +1. This is indeed a very neat approach to deal with any such limitations. | |
| Jan 9, 2019 at 17:42 | history | answered | Pranay Jaiswal | CC BY-SA 4.0 |