Deprecating some columns from a Drizzle schema

[tpilewicz]

When deleting a column from a table (to replace it with another column), my process is:

• PR1: introduce a new column that is meant to replace it, fill it with some script.
  • at this point, the code still uses the old column, because the new column is empty until the script is run.
• PR2: the code now uses the new column, which is made not nullable. Deprecate the old column, by deleting it from the schema, so we're sure the code cannot use the old column (you would get type errors).
  • The PR does not generate a migration to actually drop the column, because until the new version of the code is fully deployed, we can't be sure it's absolutely safe to drop it. (the CI first runs the schema migrations, then only deploys the new code gradually)
• PR3: generate the actual migration to drop the old column.

It would be nice if PR2 didn't have to delete the old column from the schema to ensure that the application code doesn't use it anymore. Instead, it could use some kind of setting on the old column, that allows "deprecating" it. It would mean that the column is not visible anymore in the table's typescript type, but drizzle-kit wouldn't generate a migration to drop it. Something like: description: text('description').$deprecated()

The reason I'm suggesting this is that I find it awkward to accept that in some situations, there is a difference between the typescript schema and the DB schema. We try to run some tests as part of our CI to prevent people from merging things when such a discrepancy exists (the test generates a schema migration, and returns a failure if it was able to generate it). Some option to flag the columns where this discrepancy is expected would be useful.

I looked for this in the docs, but maybe I searched a bit too specifically for deletion of columns, and should have been looking for manipulating types in general?

Thanks for reading, and for maintaining a great tool!

[tpilewicz]

Actually the real issue you will encounter if the same PR deletes the column from the Drizzle schema + creates the migration to drop it is not about typings, but about the SQL that Drizzle will generate. Assuming that the schema migration is run first and then only the new code is deployed, between these two events, any select or insert to the table will try to select/insert the dropped column, and will throw a database error.