-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic migration generation #73
Comments
I like the idea of this, but it seems like it will add quite a bit of complexity to the migration process. typeORM is super complex and it seems like to change names you need to fallback to regular migrations anyway. I may get around to at least handling the easiest case for creating/dropping tables/columns/indexes, but I'm not sure when 🤷♂️ |
Maybe take a look at Django? They have had it for years. |
I don't think this feature is that useful in Coast. Django and TypeORM migrations both rely on the model/entity/schema in the user's code. When you start a Django migration, you do:
In coast, what you do:
If you think of the process, this is clear that the reason Coast doesn't need auto migration generation is because Coast doesn't have the schema/model files to start with. In Coast, the db queries are very close to raw sql strings. I consider this a blessing because I don't really need the abstractions from ORMs. SQL is a very good abstraction for me most of the time. |
Not really, in Django you can do python manage.py migrate directly. You can completely avoid dealing with the DB. In more enterprise settings, there are technologies such as Skeema and SQL data tools to compare the before and end states of SQL schemas and generate the migrations automatically. |
My bad. I shall correct it to:
I think I know your need a bit better now. Do you wish Coast has something similar to the Models in Django where you can update in place to reflect the real state of db schema, instead of defining the incremental migrations? For example, today, to add a Personally, I still prefer the current approach where the db schema is the only source of truth. I just need to connect to the database and check the schema when I need to. I don't really feel the need to have a second source of truth from the Django Models. Though this might be helpful in an enterprise setting where developers might take extra efforts to keep their development db schemas consistent. |
In Django, you can define the state of DB and have it generate the migration i.e. the diff automatically. This saves a lot of time. Many new ORMs like TypeORM supports both the Rails style and Django style of migrations.
The text was updated successfully, but these errors were encountered: