The difference between the two is that Full (re)applies all model objects, and Smart only the model objects that have been affected between the From model version and the current point-in-time.
With platform releases, we solely use Smart upgrades to keep the upgrade as concise as it can be. We wouldn't want to reapply all Tasks and Procedures every single time because that would take a long time and would be unnecessary as the object is already there.
Whilst Full will ensure all model objects are applied, Smart will apply all model objects that are affected. You could raise the argument that is by definition more reliable, but it will certainly not be the most fast option. Note that Full generation will also remove any modifications and added objects from the database. If it is not present in the model, it will be deleted and not reapplied.
As a platform, we have the duty to make the generation as robust as it can be. Using the platform itself to build the platform, we are also the first to discover any problems that might occur after development.
If it is not present in the model, it will be deleted and not reapplied.
I am not sure what you mean by this. We have several tables that are not part of the SF model in our database that contain migration data. These tables/objects are not removed when applying a fully generated upgrade.
I have been wondring the same as the OP. Out of habit I deploy a fully generated application to our production database. And I don't when we have made a temporary change to one of the stored procedures.
But I don't think it matters much, I think both are reliable upgrade strategies. Or it should be :-)
We have several tables that are not part of the SF model in our database that contain migration data. These tables/objects are not removed when applying a fully generated upgrade.
Non-model Tables are indeed not dropped. But Badges, Change detection, Checks, Contexts, Defaults, Foreign keys, Functions, Handlers, Indexes, Instead of triggers, Layouts, Procedures, Process procedures, Table-valued functions, Tasks, Triggers and Views are.
Note that we only check the DBO schema for objects, so if they are placed in a different schema, the objects will be unaffected.
I think in the current days, with a reasonably up-to-date platform version, the “Smart” option is a good way to do your upgrades as it only contains net changes to apply.
The history of preferably using the “Full” upgrade method by many Thinkwise members is from the experience of the (much) older versions of the platform. There were certain scenarios that would not come out right with the “Smart” method or it would detect not enough entities that were actually changed.
My experience only goes from platform G7 and up where I have indeed had periods where “Full” was the way to go, but with the current supported version 2022+ I am quite comfortable using “Smart” for the upgrades.
As a Thinkwiser myself I have used the smart method for over 5 years now and I never ran into any problems with the smart upgrade it self. The misconception that the smart upgrade would not be reliable stems from either old knowledge that has long been outdated, or tampering with the database without keeping the software factory upgrade scripts in mind. I would highly advocate for using the smart methode since it’s much faster and you get a better overview of which objects are affected by the upgrade.
