Apex Code Development You need to sign in to do that
Don't have an account?
jhart 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?
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?
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).