function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Spring '14 managed package field deletion questions

According to the Spring '14 release notes, ISVs will soon be able to delete fields from managed packages.  That is great news.

I have two questions about this.

1.  Will deleted fields be available to InstallHandlers during upgrade?

For performance reasons, sometimes it's necessary to replace a field with an identical field that has "External ID" turned on.  When we do this, our InstallHandler recognizes the upgrade & launches a batch job to copy alll of the old values into the new field.

We'd then like to delete the old field.  Is that ever possible?  If I stagger my upgrades like so:

Version 1 - uses old field
Version 2 - adds new indexed field; upgrade script copies old values into new field
Version 3 - deletes old field.

What happens if a customer upgrades directly from Version 1 to Version 3?  Will it work, or will the old field be deleted before the Version 2 upgrade code runs?

2.  We recently added some lookup fields that are now preventing some customers from upgrading (b/c they are running into a "too many custom relationship fields" error).  We've decided that we'd rather remove the feature so that all customers can continue upgrading.

Now, the release notes state that deleted fields will actually remain in the subscriber org:

Subscribers who upgrade to the new package version will still have the deleted components available in their organization. They’re displayed in the Unused Components section of the Package Details page.

Does that also apply to customers whose upgrade path "skips" the deleted field entirely, eg:

Version 1 - baseline
Version 2 - introduces field X
Version 3 - deletes field X

If a customer on Version 1 cannot upgrade to Version 2 due to a "too many custom fields" limit, will they be able to upgrade directly to Version 3?  Or will the "unused components" still kinda exist and thus prevent upgrade?
Follow-up question: given that the deleted fields will be maintained in the "Unused Components" area of the customer build, does this mean they will be available to non-packaged Apex code & SOQL queries?

If so, I assume they will be available via Dynamic SOQL / Dynamic Apex within the managed package, which would be perfect for use case #1 above (replacing an unindexed field with an indexed field & needing to access the old field during the upgrade handler).