3 ms·
This sounds like one of those horrible tools like prisma which drop everything if something is not in sync on dev. We removed this type of stupid in favour of o
by anonzzzies 3y ago
This sounds like one of those horrible tools like prisma which drop everything if something is not in sync on dev. We removed this type of stupid in favour of our own which, you know, fixes this actually instead of lazily dropping everything when they cannot resolve some trivial thing, for instance, a new required field without default when there are already rows and other crap which they call ‘opinionated’. No idea why we ever used that stuff as it caused so much grief (never on prod though); after prisma/drizzle and some other ‘modern’ horrors, we mistrust everything that’s ’hip and new’ so ‘everyone uses it’. One of those hip and new things I mistrusted was Resend even though ‘suddenly everyone uses it’. I’ll wait a few years before even contemplating it.
- satvikpendem 3y agoI like that Prisma drops the database. Developer databases should be idempotent and easily reseedable with sample data. It's the same concept as cattle, not pets, from the devops world but now applied to databases. There should be nothing special about a database in development that cannot be dropped and recreated.
- anonzzzies 3y agoI don’t care about dev databases; I care about why it does it; there is no need for it, at all. > I like that Prisma drops the database. ‘Like’ ; so if it didn’t but still worked perfectly, you would complain that it didn’t?
- satvikpendem 3y ago> ‘Like’ ; so if it didn’t but still worked perfectly, you would complain that it didn’t? Yep I would, because it maintains the idempotency invariant, plus it flushes out any bugs that may exist if databases are not idempotent from seed data, that is the "why it does it."
- kgeist 3y agoWe have a script which recreates the dev DB, but developers must run the command manually so that there was an understanding what's happening.
- satvikpendem 3y agoSure, but that requires the developer to do so manually whereas in an automated system, it should just be self-generating and self-cleaning.
- janpio 3y agoQuick note that Prisma (and most of the other modern tools) never "drops everything" for normal migrations. A database reset is a solution suggested when your migration history and the actual database are not in sync, which makes it impossible for Prisma to "calculate" the migration SQL to get the database in the desired state (which is defined in Prisma schema). The commands that suggest a reset are explicitly designed for use with development databases, not with production. The "deploy migrations to production database" command on the other hand only applies already existing migration files (that you have reviewed before) and does not suggest a reset, ever.