Skip to content
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

[Feature Request] Provide Migrations API #1258

Open
tylergets opened this issue Apr 15, 2024 · 2 comments
Open

[Feature Request] Provide Migrations API #1258

tylergets opened this issue Apr 15, 2024 · 2 comments

Comments

@tylergets
Copy link

Is your feature request related to a problem? Please describe.
Prisma itself does not offer programmatic access to its migration library, originally reported here: prisma/prisma#4703

Describe the solution you'd like
It would be great if Zenstack provided a way to run migrations programmaticly.

Describe alternatives you've considered
Running the prisma command via a shell exec

Additional context
The main purpose of this for me is to allow applications to bootstrap itself without needing to run the prisma db push command or ship a preseeded DB

@ymc9
Copy link
Member

ymc9 commented Apr 18, 2024

Hi @tylergets ,

ZenStack doesn't integrate with Prisma migrate in any way today. If it does that I think it should do it in a way that's integrated with other core features (access control etc.).

I'm keeping this issue in the backlog for now to collect more feedback.

@andrictham
Copy link

andrictham commented May 28, 2024

@ymc9

If it does that I think it should do it in a way that's integrated with other core features (access control etc.).

I think ZenStack integrating with Prisma migrate (and extending its capabilities) would make a lot of sense to improve the CRUD generation feature.

Having a good workflow around migrations, especially data migrations, is much more necessary when ZenStack auto-generates client-side CRUD hooks based on the schema. Because now the client-side hooks can get out of sync with Prisma Client on the server and our database schema.

This is in contrast to using Prisma on its own, which only uses the schema to migrate the database.

As they stand now, version skew could cost queries from the auto-generated CRUD hooks to fail, if a client uses an old version of generated hooks tied to an old schema.

This is noticeable even in development when you run prisma migrate or db push to migrate your database, and queries from the client on localhost causes the app to crash or queries to fail because the database query is no longer valid.

The best practice to handle version skew of APIs is to version your APIs, so you can maintain the same shape of request/response for older clients.

How do you do that with the auto-generated RPC-style APIs?

I know that I can still manually create my own API routes using tRPC for instance, and calling the enhance() function.

But for developer productivity, it would be nice if this versioning could be handled for me, since ZenStack knows about my schema and it knows how it changes over time.

Currently data migrations are a missing piece of the Prisma workflow. But since Prisma doesn’t handle CRUD API generation and we’re expected to implement our own, that's perhaps okay. We can build our own workflows around Prisma.

With ZenStack however, let's say we follow the “expand and contract” strategy recommended by Prisma to migrate our data, and we drop the column in the “contract” step, wouldn’t old clients break because the frontend hooks mirror the Prisma API which mirrors the database columns?

The way ZenStack couples our frontend query code to our database schema is great for developer productivity, but is unfortunately less ideal when you need to migrate data. It makes our APIs resistant to change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants