Why We Chose Our Methodology
Why We Chose Our Methodology (2)
Here’s the layout for the dim_item table for a customer that has a 3.3 customized version of the modules that not only has the easily identifiable custom columns that begin with an x_ prefix (our preferred prefix for custom columns now is xx_), but also note that they have some other columns that don’t match our 3.4.1 dim_item table. These had been added at time of installation with the belief that these same columns would be added to the code base. That ended up not yet happening, so an upgrade to 3.4.1 is likely going to require even more work and investigation. Unless columns are already in the code base, treat any additions as custom.
Why We Chose Our Methodology (3)
Why We Chose Our Methodology (4)
Why We Chose Our Methodology (5)
You can see that it initially says that existing objects will be replaced.
Why We Chose Our Methodology (6)
Why We Chose Our Methodology (7)
Why We Chose Our Methodology (8)
When the patch was applied, we had selected to not change existing table, only alter them. Why are the other columns gone?
Why We Chose Our Methodology (9)
Since the new columns were added to the table and the table was not dropped, the custom columns still would contain their data, but would no longer be updated by the new procedure. A SQL Query against the table would confirm this.
Why We Chose Our Methodology (10)
As one can see, implementing patches and upgrades to tables that have any custom work done to them is not a straight forward process and likely requires a fair amount of follow up work to get the customizations back in place in the DWD metadata (the underlying SQL table can remain unchanged). It is for this reason that ideally custom work will not be done directly on standard release tables in the data warehouse or at the very least, the footprint of the customized work will mostly fall outside of the baseline code.