search

encoredev / encore

Open Source Development Platform for building robust type-safe distributed systems with declarative infrastructure
https://encore.dev
Mozilla Public License 2.0
7.77k stars 330 forks source link

Better database migration functionality #18

Open sopta opened 3 years ago

sopta commented 3 years ago

I understand that the topic of databases had to be heavily discussed to implement the current version of it. Anyway, I'd like to open a discussion (ask questions):

  1. It seems there is no way to revert a SQL migration right now. Only the .up.sql is present.

  2. For a while, I've been trying different platforms for fetching data like Hasura, Prisma, or entgo. There are different approaches to solve migrations, but from my experience, I can say that writing pure SQL migrations can be really painful. Especially, if you want to handle rollback or incremental changes. I thought it's not a big deal and I always created a scheme in an editor and then export it to a migration file. After a while, I found out it's a really cumbersome approach. For example, frameworks like Ruby on Rails, Laravel (PHP), or Buffalo has a really good approach - not using any SQL dialect, but rather use database-agnostic query builder (API).

  3. In addition to the second point, I really wish to have more control over my database workflow. Right now, it's a little bit of magic. Also, to have more freedom about choosing my database client (entgo, gorm, prisma, etc.) I know there must be some instrumentation to be able to send metric (that could be problematic), but once again, using a pure SQL in a code it's just a hell (sure it can be solved by many different way, use more SQL views, materialized views, use denormalized data from ELK, Redis, etc). I know it's a topic where people get sweaty :D .. it's just ... I don't have really good experience in using pure SQL queries.

    I hope it makes sense what I've written. So, what do you think about that? :)

eandre commented 3 years ago

Thanks @sopta, I agree with everything you said! We absolutely want to offer something much better, both on the database migrations side as well as on the database querying side. I've been working on this quite a bit already, but have had to focus my efforts elsewhere for the last couple of weeks to improve other aspects. I'll try to write down my thoughts on this in the coming days :)

sopta commented 3 years ago

Hey, sounds good :)

eandre commented 3 years ago

Hey @sopta, apologies for the delay here. I just posted #67 which proposes a solution to your third point, and lays the foundation for solving the first two points. Would love your input there :)