Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: SchemaFlow – A New Way to Handle Database Migrations (github.com/f-prime)
3 points by max0563 4 months ago | hide | past | favorite | 2 comments



I'm a little confused by three statements in your readme:

Statement 1: "However, SQL-first migration tools typically lack this separation, leading to potential schema drift. As a result, individual migration files may not accurately reflect the current database state, requiring developers to either read through all migrations or rely on external tools for a complete understanding.

Statement 2: "SchemaFlow bridges this gap for SQL-first, code-first developers. It introduces a clear distinction between schema definitions and migrations, bringing the benefits of ORM-style workflows to those who prefer writing raw SQL."

Statement 3: "SchemaFlow does not automatically generation the migration code for you. Instead, it generates a statement diff comment that you then have to replace with the appropriate statement for the given change."

Together statement 1 & 2 assert that other schema management solutions will lead to devs needing to read through the migration files and that SchemaFlow resolves this issue. But then Statement 3 (and the example in the readme) show that when I make a change, a dev needs to go into migrations file and __manually modify it__ to get it to run. Isn't this exactly what you're trying to avoid?

Why would I use a migration tool that does not write the migration for me? For the example you have it's trivial, but for a real world example this seems like it could be very error prone. What's the value prop for me as a dev here?


Also, to be clear, I like the idea of writing a schema in raw SQL and then generating a migration based on a diff from the last schema. But this seems to be that + manually writing the migration. I could just write the migration instead, right?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: