Proposal for Optimizing Table Change Deployment

» 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.

We will set the idea to Open to see how high the demand is, but we want to focus on generating an ALTER statement when the only change to the table is that a column has been added at the end.

This will not work for most applications since generated trace columns exist and are used a lot. Of course you can change how they work but I doubt any existing project will. So you’ll build a feature that won’t be used.