Should we set the completed update set on the production instance to Ignore before clone?

Suggy
Giga Sage

We want to clone PROD over DEV instance.

 

This link says "Set completed update set on the production instance to Ignore. This state ensures the update set is not reapplied when cloning the instance."

 

Is it really required to do so? If I dont do that, what exactly will happen?

Gets reapplied means what?

1 ACCEPTED SOLUTION

Nia McCash
Mega Sage
Mega Sage

On your dev instance, Update Sets that you create and complete are stored in the sys_update_set table.

Let's just say you're working with update set name 'My first update set' with a sys_id of 6a31d3973b331300bcc36da0a3efc4f5.

When you pull from your dev instance to your production instance, the update sets are staged in the sys_remote_update_set table.

The sys_remote_update_set record will have a reference to the 6a31d3973b331300bcc36da0a3efc4f5 sys_id in your dev instance so it doesn't pull the same update set again if it's already there.

When you commit that update set, the platform creates a sys_update_set record in production BUT with a different, new sys_id on production.

So now you have an update set named 'My first update set' on production with sys_id of 0bb291601bc28910277b33f3cc4bcb3a.

When you clone over your dev instance, your dev instance will then have an update set named 'My first update set' on production with sys_id of 0bb291601bc28910277b33f3cc4bcb3a.

The one with sys_id of 6a31d3973b331300bcc36da0a3efc4f5 is now gone because you cloned over it.

If you hadn't set this update set to Ignore, then when you pull for update sets from your dev instance from production, you will pull this update set back to production as one to be committed.

It doesn't matter that there's already an update set in the Retrieved Update Set [sys_remote_update_set] list that is called 'My first update set' because there is another one with a new sys_id.

 

View solution in original post

8 REPLIES 8

Nia McCash
Mega Sage
Mega Sage

On your dev instance, Update Sets that you create and complete are stored in the sys_update_set table.

Let's just say you're working with update set name 'My first update set' with a sys_id of 6a31d3973b331300bcc36da0a3efc4f5.

When you pull from your dev instance to your production instance, the update sets are staged in the sys_remote_update_set table.

The sys_remote_update_set record will have a reference to the 6a31d3973b331300bcc36da0a3efc4f5 sys_id in your dev instance so it doesn't pull the same update set again if it's already there.

When you commit that update set, the platform creates a sys_update_set record in production BUT with a different, new sys_id on production.

So now you have an update set named 'My first update set' on production with sys_id of 0bb291601bc28910277b33f3cc4bcb3a.

When you clone over your dev instance, your dev instance will then have an update set named 'My first update set' on production with sys_id of 0bb291601bc28910277b33f3cc4bcb3a.

The one with sys_id of 6a31d3973b331300bcc36da0a3efc4f5 is now gone because you cloned over it.

If you hadn't set this update set to Ignore, then when you pull for update sets from your dev instance from production, you will pull this update set back to production as one to be committed.

It doesn't matter that there's already an update set in the Retrieved Update Set [sys_remote_update_set] list that is called 'My first update set' because there is another one with a new sys_id.

 

@Nia McCash  Thank you very very much 🙂

If that was helpful, would appreciate you marking my answer as such and/or marking it as correct.

@Nia McCash Hi, can you please explain what exactly you meant by below lines:

"It doesn't matter that there's already an update set in the Retrieved Update Set [sys_remote_update_set] list that is called 'My first update set' because there is another one with a new sys_id."