I have a CDT that is in Production. As part of ongoing development a column was added to the table this CDT is based on. I DO NOT want to change the old CDT so I created a new one based on the same table with the additional column that I could use for research. Now, the objects that were related to the old CDT are showing as being related to my CDT. The old CDT is no longer showing in the Data Store. I am not looking to change the CDT in Prod at this time but I am concerned there will be development that is dependent on the old CDT.
Now that you have the background, here are my questions:
1. Why did this happen?
2. Can it be undone?
3. Why can I not query the new CDT?
4. Is it possible that the old CDT is still being recognized?
5. If objects associated to the old version of the CDT are updated and moved to another environment but the experimental CDT is not, what happens?
Discussion posts and replies are publicly visible
why would you do that? Did you do the changes in PRD directly? did you delete the old cdt or check the dependents on it?
The old CDT had not been deleted anywhere. If the question is why did I create a new CDT, it was so that I wouldn't have to do any kind of production deployment before I was ready. This was a POC, experimental. I didn't alter the original CDT because I didn't want to change the dependents. No, there were no changes made in production, either directly or through approved channels. This has occurred in a development environment.
How similar was the new CDT's name to the old CDT name?
I've had many, many instances of building different (even just slightly different) CDTs pointing to the same table, each with their own entry in the Data Store as required, and never had an internal conflict like what you describe.
You should check if you have dependents on the old CDT. Anyways, if you are adding a new column, I would really consider doing the modification on the old CDT and just use one CDT,
The DB is going to be affected in the same way, and replacing CDTs can be much more of a pain.