[RFC] Remove the blitz db command in favor of using prisma directly

[flybayer]

Prisma 2.13 introduces an overhauled migration system and new CLI commands.

That release is very welcome and is a great step towards Prisma meeting all production needs. With this release, their cli now has two db related commands, prisma migrate and prisma db, both with various sub commands.

However this causes a bit of an issue because we only have one command blitz db with various sub commands.

After thinking about this for awhile, I'm convinced the best choice is to remove our blitz db command in favor of using the prisma cli directly. The prisma migrations are very powerful but also a bit complex, and they likely they will add new commands and features in the future.

While I like the idea of having a blitz specific command for this, another big reason for adding it back at the start was a simple db migration required running three prisma commands. And Prisma didn't support db resets or db seeding.

But now the new cli only requires one command to migrate, prisma migrate dev, has prisma migrate reset, and they are adding a seed command soon. And for production, they have a specific command, prisma migrate deploy.

Another benefit from removing our command is reducing confusion about this integration and we can fully direct people to the prisma docs for this instead of having some of their docs in our docs.

The first step would be to remove all blitz db commands except for blitz db seed. And then remove that once prisma adds their seed feature.

What do you think?

[itsdillon]

I get what you're saying. It can also allow room for other database layers, (ie; Fauna)

But... I think removing the blitz db command is starting to stray away from the original philosophy blitz stands for: "Everything end-to-end from the database to the frontend."

The little detail of not changing context from using the blitz cli to the prisma cli could mean a lot to some people. Would aliasing the prisma commands with blitz work?

[alexturpin]

I wasn't sure how to feel about it at first, because somewhat like the commenter above, I liked the idea of everything going through Blitz.

But thinking about it some more, what I love about Blitz is that I have escape hatches everywhere, and how little "magic" there is. What's more, removing code always feels great.

So I'm fully supportive of this move. My "attenuation" suggestion would be to have the relevant Prisma commands still featured in our documentation, if only to showcase a typical "Blitz DB development flow".

[kulshekhar]

This makes a lot of sense and seems like a step in the right direction. Delegating specific tasks to tools that are purpose built for those tasks makes a lot of sense. It avoids any impedance mismatch/divergence between blitz and the underlying too while reducing the maintenance overhead on the blitz project/developers.

[jackbravo]

I agree completely:

• prisma already has clear documentation, as mentioned by @alexturpin, we can just document the happy or usual path and avoid documenting all cases and parameters
• we avoid oversimplifying their commands leaving some options out, specially because they are also on a preview state so they are prone to changing at any given moment
• we have less code to maintain

[HeyGarrison]

This seems like the right direction, because Prisma is only getting better with their CLI.

What about if we added some shortcut commands for Prisma in package.json to kind of alias some of Prisma's commands?

[flybayer]

What shortcuts would you add?

[HeyGarrison]

Probably just a simple "migrate" shortcut just so it's right in front of newbs like me. I upgraded tried out Prisma 2.13 last night and had trouble doing migration simply because there were so many potential commands.

[jackbravo]

the other thing I saw, is that current blitz commands already load the correct .env.local file, while prisma commands do not. They only load the general .env file. How can this be fixed?

[flybayer]

the other thing I saw, is that current blitz commands already load the correct .env.local file, while prisma commands do not. They only load the general .env file. How can this be fixed?

Oh, that's a very good and important point 🤔

[bravo-kernel]

As a noob user, I think it would be most valuable if the .env issue could be solved and this stuff would "just work".

I just bumped into this while trying to get acquainted with Blitzjs, using the tutorial on Windows with MySQL 8. It seems a fresh install is then dropping the database as described here.

After reading through all the tickets I had to give up:

1. updating package.json versions to 12.3
2. tried suggested workaround npx prisma migrate: incomplete command
3. tried npx prisma migrate dev: error stating I need to pass --preview-feature
4. tried npx prisma migrate dev --preview-feature: error about missing env var DATABASE_URL
5. updated my .env file
6. tried npx prisma migrate dev --preview-feature again: error The migrations folder contains migration files from an older version of Prisma Migrate which is not compatible

UPDATED finally realized I had to also remove the existing migration directories. After that this command worked npx prisma migrate dev --preview-feature.

[abuuzayr]

I think this move is in a good direction! For the blitz team to always write code to match how prisma would evolve I think would be a mammoth task of cat and mouse. Peeling off a layer over prisma commands would help developers - at least - while troubleshooting, as if they were anything like me, they would go "oh, i'm running a prisma command, perhaps I should look in there for help". There were times when I created an issue related to a blitz db command and was told to create the issue in the prisma repo instead, so this would definitely solve some confusion.

Perhaps it would be OK to have additional handlers in future like what you mentioned about blitz db seed, but if prisma commands can be used as they are, i think it would be better for them to be used instead.

[flybayer]

As @jackbravo brought up, using prisma CLI directly doesn't work with the extra env files like .env.development and .env.test.

I'm talking to Prisma about a solution for this, but in the meantime I think the best compromise is to add a blitz prisma command that will proxy everything to the prisma CLI after loading the env vars. Ex: blitz prisma migrate dev