13 Replies
is there a reason all of these statements don't run in a transaction?
had an issue because this partially failed and didn't notice it dropped the primary key
it's also weird because it doesn't try to do this a staging env
That's what I don't like about the push command, it just runs like a migration, but without the migration file.
You don't get a change to look at the sql before you run it, you just pray there's no issues
That's probably why it's only recommended for dev environment
this was less of an issue for me with planetscale because the "go to production" phase is different
i just need to understand why it can't be run in a tx
additionally would be good to have a plan -> commit -> apply flow where it shows you wht changes it's going to make and you accept them
Maybe it should run in a tx 🤔
A workaround would be to generate the migration, take note of the sql file, and then drop it if needed
Without applying it obvsly
yeah
This might be a good idea for a new issue if it doesn't exist in the drizzle-kit-mirror repo
a flow i'd actually love would be similar to git commit
where it opens up in your editor and you can make changes
That's basically a migration but in the console lol
yeah but still avoids having to maintain migration state
Why don't you like migrations?
I love them, I feel in solid ground
they introduce some annoyances when workign with teams and git
doubled layered version tracking problem, it's written about a decent amount
oh there is a
--strict
optionlol there you go
The behavior of postgres push is the same as it was in MySQL and SQLite; that's the only reason why there is no tx conext
For now, it sounds good to have a transaction, because we don't have support, for example, for
CREATE INDEX CONCURRENTLY
, which can't be run in a transactional context. Perhaps, for this case, we can add an option to drizzle.config to determine how the push should be executed, but I'm not sure if it's the best approach. I haven't thought about it yet