2

We are moving one of the projects to SFDX. When I push this cachePartition into a scratch org:

<?xml version="1.0" encoding="UTF-8"?>
<PlatformCachePartition xmlns="http://soap.sforce.com/2006/04/metadata">
    <isDefaultPartition>false</isDefaultPartition>
    <masterLabel>myCache</masterLabel>
    <platformCachePartitionTypes>
        <allocatedCapacity>5</allocatedCapacity>
        <allocatedPurchasedCapacity>0</allocatedPurchasedCapacity>
        <allocatedTrialCapacity>0</allocatedTrialCapacity>
        <cacheType>Organization</cacheType>
    </platformCachePartitionTypes>
    <platformCachePartitionTypes>
        <allocatedCapacity>0</allocatedCapacity>
        <allocatedPurchasedCapacity>0</allocatedPurchasedCapacity>
        <allocatedTrialCapacity>0</allocatedTrialCapacity>
        <cacheType>Session</cacheType>
    </platformCachePartitionTypes>
</PlatformCachePartition>

I get an error:

Total allocated capacity [5] exceeds the org limit [3].

Fine, with this line change <allocatedCapacity>3</allocatedCapacity> I can successfully push my code.

But the thing is I really need 5. Use Platform Cache with Scratch Orgs says

Your scratch org has 3 MB of platform cache

But what should I do? This is a part of metadata which we track via VCS. The only option I see is a script to replace 5 to 3 on every push. It's annoying.

Does anybody know a better way to deal with such cases?

  • 2
    Surely there is no need for any cache at all on a scratch org since these are only providing a performance boost and your code should be written to work even if no cache exists... in which case, just exclude the cache definitions from push and pull via the .forceignore file... – Phil W Oct 5 '19 at 8:28
  • @PhilW, great idea, thanks. The only drawback of this approach is that force:source:convert will not work and I need to remember to remove cache definitions from .forceignore when converting source to metadata. – Eduard Oct 6 '19 at 17:26
1

It is best practice to write the Apex code to work whether or not platform caches exist. As such you should be able to simply use the .forceignore definition to exclude the platform cache definitions from push and pull operations and allow the scratch orgs to simply operate without the platform caches.

| improve this answer | |
  • Just turned my comment into an answer. Feel free to comment further. – Phil W Oct 6 '19 at 21:04
  • As per my last comment, we are using SFDX and we keep our source in this format in our VCS. Now the issue is that if I add the cache definition into the .forceignore file, the force:source:convert command will not convert the cache definition in the metadata format. Hence, deployment will be without this setting. This makes the whole idea of storing cache definition in VSC pointless, unless you always remember to adjust .forceignore before running force:source:convert – Eduard Oct 7 '19 at 7:28
  • In what circumstance do you need to do the force:source:convert at all? We hold the structure in the one (source) format and when we need to deploy to a non-DX org we just use force:mdapi:deploy. – Phil W Oct 7 '19 at 7:54
  • Doesn't force:mdapi:deploy require the files to be in the metadata format? and you need to use force:source:convert to convert source into metadata. – Eduard Oct 7 '19 at 8:13
  • 1
    No, it accepts deploying it from source format. – Phil W Oct 7 '19 at 9:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.