3 ms·
With SQL Server Data Tools (SSDT) we get desired-state schema management, which seems much better than writing any kind of migrations. In practice it works well
by electroly 5y ago
With SQL Server Data Tools (SSDT) we get desired-state schema management, which seems much better than writing any kind of migrations. In practice it works well, and the code you're writing is plain DDL. I wonder why it's not more commonly seen in other ecosystems.
- jeltz 5y agoHow do you handle locks and transforming data? Usually those two things is what forces you to write migrations manually.
- electroly 5y agoSSDT gets you most of the way but not all the way there. It can rebuild a table by copying the rows if you're changing things that are evident from a diff of the production schema against your desired state, if it's not possible with ALTER TABLE. But for complicated arbitrary transformations, it does make you use a trapdoor where you write a migration script that gets executed after the desired state is applied. In practice, we consciously avoid doing this, but we are perhaps making sacrifices for the tool's limitations. I've occasionally done hacks like creating a new table with the desired new shape, then creating a view that converts the old data to the new format and merges it with the new data. SSDT is capable of deploying that, but it's not the greatest situation.
- evanelias 5y agoThis approach (declarative schema management) is definitely gaining in popularity. I'm the author of https://www.skeema.io https://www.skeema.io which provides declarative schema changes for MySQL and MariaDB -- it's now used by a few hundred companies and is downloaded/installed 30k times per month, due in part to heavy usage in CI/CD pipelines. There are a few other tools in this space, such as Migra and sqldef.