Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hassle-Free Database Migrations with Prisma Migrate

prisma.io

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Hassle-Free Database Migrations with Prisma Migrate

#21

Post by IceDane »

I just recently started using Prisma for a work project and so far I am very pleasantly surprised. I don't think I'll ever want to use something like TypeORM or similar again.

We also used their Nexus library to set up a graphql server, and that also worked pretty well. There is a library which bridges the gap between prisma and nexus, making it super easy to set up CRUD operations, but it seems we started using prisma right in the middle of them totally revamping that library.

The fact that the prisma developers are aware of technical debt to the point that they are able and willing to totally ice a project in order to redesign it properly is also something I like, because sometimes that is really what you need to do, but most aren't willing to do. Naturally, this can cause some friction, but I work in an industry where I regularly have to work with horrible libraries and software written by developers that don't care and just keep on piling up crap on top of their already huge pile of crap.

Congrats and thanks for all the hard work.

Re: Hassle-Free Database Migrations with Prisma Migrate

#22

Post by jph »

bionhoward wrote: post #12

Definitely got me interested, and I know I ought to just use Postgres, but I'm really keen to use openCypher. Would it be possible to hook prisma up to graph dbs? (bion)-[:loves]->(graphs)

Postgres has a graph extension work in progress, that may interest you: https://age.incubator.apache.org/

"AGE is an acronym for A Graph Extension... The goal of the project is to create single storage that can handle both relational and graph model data so that users can use standard ANSI SQL along with openCypher, the Graph query language."

Re: Hassle-Free Database Migrations with Prisma Migrate

#23

Post by tomhoule »

linkdd wrote: post #6

What I need from migrations is collaboration. When I make a schema migration locally and push it to the repository, then 3 other PRs with their own migrations are being merged before mine, it is very likely that my local database will be in the wrong state. Correct me if I'm wrong, but using an ORM (be it Django, Prisma, liquibase, ...) to handle your migrations will only generate the SQL queries for you, it won't ha…

(prisma migrate team member here)

The development flow in migrate (the `migrate dev`) command is quite pedantic: it will check things like migrations missing from your migrations folder but already applied to the dev database, or migrations that were modified since they were applied (via a checksum) and guide you towards resolving the problem. That can happen because of merges, but even more commonly when you are just switching branches locally, or editing migrations.

We're also looking into ways to integrate with your CI and review process to provide more insight, for example when your branch gets stale and you need to "rebase" your migrations on the migrations from the main branch. It's something we are actively exploring, and we're more than happy to get your feedback and ideas on github/slack :)

My personal view is that _some level_ of consciousness of the migration process (schema and data) will always be required from developers on large enough projects. What we can do is build tools that help people getting their migrations right, but it can't be completely automated. There's a lot more to do, now that we have a stable, production ready foundation.

Re: Hassle-Free Database Migrations with Prisma Migrate

#24

Post by linkdd »

tomhoule wrote: post #23
linkdd wrote: post #6

What I need from migrations is collaboration. When I make a schema migration locally and push it to the repository, then 3 other PRs with their own migrations are being merged before mine, it is very likely that my local database will be in the wrong state. Correct me if I'm wrong, but using an ORM (be it Django, Prisma, liquibase, ...) to handle your migrations will only generate the SQL queries for you, it won't ha…

(prisma migrate team member here) The development flow in migrate (the `migrate dev`) command is quite pedantic: it will check things like migrations missing from your migrations folder but already applied to the dev database, or migrations that were modified since they were applied (via a checksum) and guide you towards resolving the problem. That can happen because of merges, but even more commonly when you are jus…

Thank you for your clarification.

I like to think about a single migration being a function and a migration history multiple functions being composed.

Category theory's main subject (I think) is composition and a lot of good ideas can be taken from there (see this paper: "Functorial Data Migration"[1]).

There is an obvious relationship between a schema and the data, and a migration operates on both. The schema might be versioned, but unless you use a Schema-less database (ie: MongoDB) and handle the data versioning application side, your data is not.

Any document/graph-based database can avoid this problem by assigning a version to your documents (like apiVersion+kind in Kubernetes), then the application should know how to process each version of the data.

In an SQL database, it would require different tables which complexify the data model.

IMHO, in every case, you need to handle some of the logic application side or maintain an history of your data (bye-bye storage space?).

[1] - http://math.mit.edu/~dspivak/informatics/CD-FDM.pdf

Re: Hassle-Free Database Migrations with Prisma Migrate

#25

Post by lf-non »

We have been using liquibase[1] in a variety of java & non-java projects and it has proven to be a really flexible & powerful open source solution.

It shines really well when you need to manage not just tables and views, but also stored procedures, custom types, triggers etc.

[1] https://www.liquibase.org/

Re: Hassle-Free Database Migrations with Prisma Migrate

#26

Post by tomhoule »

linkdd wrote: post #24
tomhoule wrote: post #23

Earlier quoted context omitted.

(prisma migrate team member here) The development flow in migrate (the `migrate dev`) command is quite pedantic: it will check things like migrations missing from your migrations folder but already applied to the dev database, or migrations that were modified since they were applied (via a checksum) and guide you towards resolving the problem. That can happen because of merges, but even more commonly when you are jus…

Thank you for your clarification. I like to think about a single migration being a function and a migration history multiple functions being composed. Category theory's main subject (I think) is composition and a lot of good ideas can be taken from there (see this paper: "Functorial Data Migration"[1]). There is an obvious relationship between a schema and the data, and a migration operates on both. The schema might…

Ooh it's interesting you mention David Spivak's work, I got interested into it recently. Some of these ideas are being commercialized by https://conexus.com/ (he's a co-founder). You might also be interested by Project Cambria[1] for novel ideas about data and schema migrations based on lenses.

We haven't gone in the fancy direction yet, because we wanted to first have the tool our users told us they were missing - namely a migration tool similar to what other ORMs have, but playing on the strengths of the Prisma schema. But these novel ideas about migrations are definitely something we always read with a lot of interest and love to discuss — I hope we get to implement something radical like that some day.

[1]: https://www.inkandswitch.com/cambria.html

Re: Hassle-Free Database Migrations with Prisma Migrate

#27

Post by ampdepolymerase »

IceDane wrote: post #21

I just recently started using Prisma for a work project and so far I am very pleasantly surprised. I don't think I'll ever want to use something like TypeORM or similar again. We also used their Nexus library to set up a graphql server, and that also worked pretty well. There is a library which bridges the gap between prisma and nexus, making it super easy to set up CRUD operations, but it seems we started using pris…

Prisma needs to make the Hasura-style automatic API generation easier. Currently it requires too much setup and moving parts.
Post reply on HN