Skip to main content

Hi,

A suggestion for the improvement to the current deployment process for table changes in our Software Factory. At present, when a table undergoes a change, the deployment package generates a CREATE script for the entire table. This approach often results in significant data migration, which can be time-consuming during deployment.

To improve efficiency, I propose that if a table change involves adding a column at the end, the deployment package should generate an ALTER statement instead. This modification would significantly expedite the deployment process.

Implementing this change would be highly beneficial for us, as the order of columns in a table is generally not critical. The GUI is configured in the Subject, and for views, handlers, triggers, etc., the code should specify the correct columns explicitly.

Could this be considered as an optional feature in the deployment package?

Thank you for considering this suggestion.

Blommetje

» as the order of columns in a table is generally not critical.
Given the fact that when do an alter on the table, in stead of recreate of the tabel, it could be possible that a SQL statement is written where we indeed depend upon the actual column order from SF.

This is not something that we should depend on, as this can result in strange and erroneous behavior on runtime.
So as nive to have, if there is a sql in a function (/ template ect) that depend upon the actual ordering of the column from SF. Say for example a SELECT INTO without a column definition in the select. That then a warning / validation message is raised during the build/ validation stages.

 

» as the order of columns in a table is generally not critical.
Given the fact that when do an alter on the table, in stead of recreate of the tabel, it could be possible that a SQL statement is written where we indeed depend upon the actual column order from SF.

This is not something that we should depend on, as this can result in strange and erroneous behavior on runtime.
So as nive to have, if there is a sql in a function (/ template ect) that depend upon the actual ordering of the column from SF. Say for example a SELECT INTO without a column definition in the select. That then a warning / validation message is raised during the build/ validation stages.

 

In general it is always advised to use a column list for inserts. Furthermore I think you should always do an impact analysis of any data model change you maken. Insert into’s without a column list will fail when the table definition is changed, regardless of where the new column has been added.

https://docs.thinkwisesoftware.com/docs/sf/guidelines_sql_formatting#dos

I do however agree that it would be great if somehow the SF would analyze any model changes and check for possible impact on the code / breaking changes. It could do this via code(template) analysis or perhaps by parsing the current codebase on the to-be-created database. Obviously the latter approach should be something you can schedule since this would be pretty resource intensive.

Terms & ConditionsCookie settings