Reduce field size #150
Reduce field size #150
Conversation
|
Please sign the CLA so I can review these contributions. https://github.com/mitchspano/apex-trigger-actions-framework/blob/main/docs/contributing.md |
| <label>Order</label> | ||
| <precision>18</precision> |
There was a problem hiding this comment.
Why? This field is used in the framework's logic and is not related to an API name with limited length.
There was a problem hiding this comment.
You are right there is not a specific or hard limit here. However, the goal is to reduce storage size and reducing precision DOES make each record take up less space. I would argue that a precision of 18 is excessively large. No one will ever need to be able to order 100 trillion trigger actions (x1000 decimal places). I am proposing cutting storage space by 1/3 and limiting to 9999 actions without using decimals or 1 million if using the 2 decimals also. This should still leave plenty of breathing room to make your order values every 10 or even 100 to leave space in between for future actions.
There was a problem hiding this comment.
Since every record is 2k of storage space the way Salesforce measures it, how does this change make a meaningful difference in anything?
There was a problem hiding this comment.
@dschach Because this is not an SObject record, it is a custom metadata type. For Custom Metadata types, every character DOES matter and does change the used storage against the 10MB global limit.
https://help.salesforce.com/s/articleView?id=platform.custommetadatatypes_limits.htm&type=5
Relavent note:
Record size is based on the maximum field size of each field type, not the actual storage that’s used in each field. When adding fields to a custom metadata record, use the appropriate type and specify a length that doesn’t exceed what’s needed for your data. This action helps you avoid reaching the cached data maximum. For example, if you create a US social security number (SSN) field, select the Text data type, and specify a length of 9. If you select Text Area, the field adds 255 characters to the usage count for each record, regardless of the number of characters entered.
There was a problem hiding this comment.
I learned something; thank you. So the savings of 12 characters with an org limit of 10,000,000 is something that would be significant?
(That's obviously tongue in cheek because I do agree that every optimization should be considered.)
There is a chance here, though, that an org went for ridiculously-spaced values here and those will be cut off. Mitch may have made a decision in version 1 that we can't undo, no matter how much we may want to.
| <required>true</required> | ||
| <scale>3</scale> | ||
| <scale>2</scale> |
There was a problem hiding this comment.
This will truncate data for anyone who is already using all 3 decimal places.
Let's keep it at 3.
| <required>true</required> | ||
| <scale>3</scale> | ||
| <scale>2</scale> |
There was a problem hiding this comment.
This will truncate data for anyone who is already using all 3 decimal places.
Let's keep it at 3.
Custom Metadata Types have a small (10Mb) limit for the total amount you can store in the records. Storage usage is determined by a fixed per record size that is affected by the field size.
Current field size is set to the max for all field types. However, several fields reference API names which have documented max lengths they can be in Salesforce. Any field size greater than this is "wasted" storage as it will never be needed.
Changes
Reduced fields referencing Salesforce APIs to the maximum allowed API Name length for the type
Updated fieldManagability to SubscriberControlled so that the framework could be included in a managed package.
Tests pass
Appropriate changes to README are included in PR