4 ms·

Have you tried drizzle? If so, what's your beef? (The only one I've had is lack of down-migrations)

1st1 2y ago
Addressing your core question: Drizzle is a great ORM with a tastefully designed API—it's clearly a product of love. But it’s still an ORM, and it’s confined by certain design boundaries that come from being a library. For example, what if you want to use TypeScript, Go, and Python on your backend? Do you run three ORMs, each with different APIs? With Gel, you have one data model and a unified querying layer—the true source of truth. We have a blog post about that and more [1]. --- By the way, if you visit Drizzle’s website, you’ll see that Gel is one of their biggest sponsors. We worked closely with Drizzle to ship a first-class integration with Gel. You can use Gel’s schema and migrations, and Drizzle will just work. You can even use the Drizzle query builder and EdgeQL side by side if you want. [1] https://www.geldata.com/blog/a-solution-to-the-sql-vs-orm-dilemma https://www.geldata.com/blog/a-solution-to-the-sql-vs-orm-di...
- valenterry 2y ago
  > Do you run three ORMs, each with different APIs? Yes and you absolutely have to. That's not a disadvantage, it's just how it is. Because SQL is the absolute bare minimum. The lowest common standard. And not a great one. Null handling and typesystem for example are way inferior to those of good programming languages. So why would I leave those productivity gains on the table? Using EdgeQL simple means I have another programming language at hand. > EdgeDB has a robust type system that's most [sic] comprehensive that most ORMs Well yeah. And it is inferior to the programming language I use. Hence, this comes at a disadvantage to me. > We've also built a query builder for TypeScript Aha, so then... why not build a query builder for every language, just like with ORMs? Sorry, not convinced. We would be better off by improving on SQL itself.
  - 1st1 2y ago
    > Yes and you absolutely have to. That's not a disadvantage, it's just how it is. Because SQL is the absolute bare minimum. The lowest common standard. And not a great one. Null handling and typesystem for example are way inferior to those of good programming languages. So why would I leave those productivity gains on the table? I think... we're in a agreement? :) EdgeQL doesn't have a NULL (it's a set-based language and NULL is an empty set, this tiny adjustment makes it easier to reason about missing data). And because it also has a more robust type system, allows for limitless composition and easy refactoring, it has far greater DX than SQL => you're more productive. There's a footnote here: EdgeQL doesn't support some of the SQL capabilities just yet, namely window functions and recursive CTEs. But aside from that it is absolutely a beast. > Well yeah. And it is inferior to the programming language I use. Hence, this comes at a disadvantage to me. Maybe, but I'm curious how you arrived to that conclusion. I assume you mean that using the power of a high-level programming language you can force ORM to complete submission and that's just not true. Most of the time you'll either have grossly inefficient multi-roundtrip query code (hidden from you) or let ORM go and use SQL. Obviously that's an extreme scenario, but it's surprisingly common in complex code bases and logic. > Aha, so then... why not build a query builder for every language, just like with ORMs? We are. We started with improving the network protocol (it does less round-trips than Postgreses and is stateless) and crafting client libraries for MANY languages. All client libraries support automatic network & transaction error recovery, automatic connection pooling, and have generally great and polished API. Not to mention they are fast. We do have a query builder for TypeScript. But we also have codegen for every language we support: place an .edgeql file in your project and you get fully typed code out of that. That said, we will eventually have query builders for every language we support. There's only so much you can do in 3 years since we announced 1.0. > Sorry, not convinced. We would be better off by improving on SQL itself. Significantly improving SQL without starting from scratch isn't possible. Adding sugar - surely is possible, but we are 100% that the productivity boost we deliver with EdgeQL is worth going all in (and our users agree with us). In any case, with Gel 6 we have full SQL support (except DDL), so it's possible to use Gel along with ORMs if that's needed. We are not SQL haters at all. We have this blog post that was on HN front page a few times, it's a good read and explains our position: https://www.geldata.com/blog/we-can-do-better-than-sql https://www.geldata.com/blog/we-can-do-better-than-sql
  - lelanthran 2y ago
    > And not a great one. Null handling and typesystem for example are way inferior to those of good programming languages There is no mainstream programming language that I know off that offers what are table stakes for an RDBMS. For example, even trivial SQL things like a constraint saying 'at least one of these two fields must be empty, but both can't be empty' is missing in the "advanced" type systems in mainstream languages.
    - valenterry 2y ago
      First of all, your example constraint is not possible to be statically expressed in SQL anyways. In the typesystem, that is. Sure, you can create a constraint for `'at least one of these two fields must be empty, but both can't be empty'` but that will only be applied at runtime. It's not like any dmbs (to my knowledge) will reject the query at parse-time. Or else, please show me an example of how you would do that. (and don't use constraints or indexes, because those only work at runtime) Second, I deliberately said "good programming languages" and you changed that to "mainstream programming language". You know what? If all your mainstream programming languages (however you count or define those) don't support that stuff, maybe it's time to move on and choose a better language. In Scala at least, it's trivially possible to define such a constraint with types. That ensures that you will never by accident violate that constraint. And that is guaranteed at compile time, so no one is gonna wake you up in the night because your query failed due to that condition you specified. If you don't believe me, I'm happy to show you the code to encode that logic.
      - lelanthran 2y ago
        > First of all, your example constraint is not possible to be statically expressed in SQL anyways. In the typesystem, that is. So? The DB will prevent you from violating the constraints, because it cannot tell in advance (i.e. before getting the query with the data in it) whether the data violates the constraint. > It's not like any dmbs (to my knowledge) will reject the query at parse-time. What parse-time? echo "INSERT INTO tbl_test (c_one, c_two) VALUES (3, 4); Where's the parse-time in that? TBH, I am still failing to see your point - this looks like an artificial restriction (the query must be rejected before you present it to the DB). Whether you call it runtime or compile-time or parse-time, the DB will not let you violate the type safety by accident. The point is that the DB will enforce the constraints. > Second, I deliberately said "good programming languages" and you changed that to "mainstream programming language". Well, if your bar for "good programming languages" rules out all the mainstream languages, what's the point of even discussing your point? The point you are making then becomes irrelevant. > If all your mainstream programming languages (however you count or define those) don't support that stuff, maybe it's time to move on and choose a better language. For better or worse, the world has rejected those better languages and relegated them to niche uses. Shrieking shrilly about your favourite languages aren't gonna make them more popular. You know what's more realistic? Teaching the users of the "poorer" languages that they can get all those benefits of type enforcement in their DB without needing to switch languages. > In Scala at least, it's trivially possible to define such a constraint with types. In more than a few languages it's possible to do that. I'm thinking more Prolog, and specific SAT solvers than Scala, though. There's benefits in doing so. However, the minute you plug an RDBMS into your system, many benefits can be gained without switching languages at all. Like real constraints for XOR or composite uniqueness, referential integrity, NULL-prevention, default values, etc.
re-thc 2y ago
Drizzle still lacks a lot of features / stability (bug fixes required). Hopefully it improves over time.
- 1st1 2y ago
  Having worked with the core team I can only say that they are amazing. I'm sure they'll figure it out, but database tech is gnarly. Takes time.
alangou 2y ago
For me, personally, I do a ton of fullstack work in JavaScript-land, but also have Python services for ML-heavy needs, and it’s nice to define one schema that at its root is still SQL while generating query clients for multiple languages.

1st1 2y ago

Addressing your core question: Drizzle is a great ORM with a tastefully designed API—it's clearly a product of love. But it’s still an ORM, and it’s confined by certain design boundaries that come from being a library. For example, what if you want to use TypeScript, Go, and Python on your backend? Do you run three ORMs, each with different APIs? With Gel, you have one data model and a unified querying layer—the true source of truth. We have a blog post about that and more [1]. --- By the way, if you visit Drizzle’s website, you’ll see that Gel is one of their biggest sponsors. We worked closely with Drizzle to ship a first-class integration with Gel. You can use Gel’s schema and migrations, and Drizzle will just work. You can even use the Drizzle query builder and EdgeQL side by side if you want. [1] https://www.geldata.com/blog/a-solution-to-the-sql-vs-orm-dilemma https://www.geldata.com/blog/a-solution-to-the-sql-vs-orm-di...

valenterry 2y ago
> Do you run three ORMs, each with different APIs? Yes and you absolutely have to. That's not a disadvantage, it's just how it is. Because SQL is the absolute bare minimum. The lowest common standard. And not a great one. Null handling and typesystem for example are way inferior to those of good programming languages. So why would I leave those productivity gains on the table? Using EdgeQL simple means I have another programming language at hand. > EdgeDB has a robust type system that's most [sic] comprehensive that most ORMs Well yeah. And it is inferior to the programming language I use. Hence, this comes at a disadvantage to me. > We've also built a query builder for TypeScript Aha, so then... why not build a query builder for every language, just like with ORMs? Sorry, not convinced. We would be better off by improving on SQL itself.
- 1st1 2y ago
  > Yes and you absolutely have to. That's not a disadvantage, it's just how it is. Because SQL is the absolute bare minimum. The lowest common standard. And not a great one. Null handling and typesystem for example are way inferior to those of good programming languages. So why would I leave those productivity gains on the table? I think... we're in a agreement? :) EdgeQL doesn't have a NULL (it's a set-based language and NULL is an empty set, this tiny adjustment makes it easier to reason about missing data). And because it also has a more robust type system, allows for limitless composition and easy refactoring, it has far greater DX than SQL => you're more productive. There's a footnote here: EdgeQL doesn't support some of the SQL capabilities just yet, namely window functions and recursive CTEs. But aside from that it is absolutely a beast. > Well yeah. And it is inferior to the programming language I use. Hence, this comes at a disadvantage to me. Maybe, but I'm curious how you arrived to that conclusion. I assume you mean that using the power of a high-level programming language you can force ORM to complete submission and that's just not true. Most of the time you'll either have grossly inefficient multi-roundtrip query code (hidden from you) or let ORM go and use SQL. Obviously that's an extreme scenario, but it's surprisingly common in complex code bases and logic. > Aha, so then... why not build a query builder for every language, just like with ORMs? We are. We started with improving the network protocol (it does less round-trips than Postgreses and is stateless) and crafting client libraries for MANY languages. All client libraries support automatic network & transaction error recovery, automatic connection pooling, and have generally great and polished API. Not to mention they are fast. We do have a query builder for TypeScript. But we also have codegen for every language we support: place an .edgeql file in your project and you get fully typed code out of that. That said, we will eventually have query builders for every language we support. There's only so much you can do in 3 years since we announced 1.0. > Sorry, not convinced. We would be better off by improving on SQL itself. Significantly improving SQL without starting from scratch isn't possible. Adding sugar - surely is possible, but we are 100% that the productivity boost we deliver with EdgeQL is worth going all in (and our users agree with us). In any case, with Gel 6 we have full SQL support (except DDL), so it's possible to use Gel along with ORMs if that's needed. We are not SQL haters at all. We have this blog post that was on HN front page a few times, it's a good read and explains our position: https://www.geldata.com/blog/we-can-do-better-than-sql https://www.geldata.com/blog/we-can-do-better-than-sql
- lelanthran 2y ago
  > And not a great one. Null handling and typesystem for example are way inferior to those of good programming languages There is no mainstream programming language that I know off that offers what are table stakes for an RDBMS. For example, even trivial SQL things like a constraint saying 'at least one of these two fields must be empty, but both can't be empty' is missing in the "advanced" type systems in mainstream languages.
  - valenterry 2y ago
    First of all, your example constraint is not possible to be statically expressed in SQL anyways. In the typesystem, that is. Sure, you can create a constraint for `'at least one of these two fields must be empty, but both can't be empty'` but that will only be applied at runtime. It's not like any dmbs (to my knowledge) will reject the query at parse-time. Or else, please show me an example of how you would do that. (and don't use constraints or indexes, because those only work at runtime) Second, I deliberately said "good programming languages" and you changed that to "mainstream programming language". You know what? If all your mainstream programming languages (however you count or define those) don't support that stuff, maybe it's time to move on and choose a better language. In Scala at least, it's trivially possible to define such a constraint with types. That ensures that you will never by accident violate that constraint. And that is guaranteed at compile time, so no one is gonna wake you up in the night because your query failed due to that condition you specified. If you don't believe me, I'm happy to show you the code to encode that logic.
    - lelanthran 2y ago
      > First of all, your example constraint is not possible to be statically expressed in SQL anyways. In the typesystem, that is. So? The DB will prevent you from violating the constraints, because it cannot tell in advance (i.e. before getting the query with the data in it) whether the data violates the constraint. > It's not like any dmbs (to my knowledge) will reject the query at parse-time. What parse-time? echo "INSERT INTO tbl_test (c_one, c_two) VALUES (3, 4); Where's the parse-time in that? TBH, I am still failing to see your point - this looks like an artificial restriction (the query must be rejected before you present it to the DB). Whether you call it runtime or compile-time or parse-time, the DB will not let you violate the type safety by accident. The point is that the DB will enforce the constraints. > Second, I deliberately said "good programming languages" and you changed that to "mainstream programming language". Well, if your bar for "good programming languages" rules out all the mainstream languages, what's the point of even discussing your point? The point you are making then becomes irrelevant. > If all your mainstream programming languages (however you count or define those) don't support that stuff, maybe it's time to move on and choose a better language. For better or worse, the world has rejected those better languages and relegated them to niche uses. Shrieking shrilly about your favourite languages aren't gonna make them more popular. You know what's more realistic? Teaching the users of the "poorer" languages that they can get all those benefits of type enforcement in their DB without needing to switch languages. > In Scala at least, it's trivially possible to define such a constraint with types. In more than a few languages it's possible to do that. I'm thinking more Prolog, and specific SAT solvers than Scala, though. There's benefits in doing so. However, the minute you plug an RDBMS into your system, many benefits can be gained without switching languages at all. Like real constraints for XOR or composite uniqueness, referential integrity, NULL-prevention, default values, etc.

re-thc 2y ago

Drizzle still lacks a lot of features / stability (bug fixes required). Hopefully it improves over time.

1st1 2y ago
Having worked with the core team I can only say that they are amazing. I'm sure they'll figure it out, but database tech is gnarly. Takes time.

alangou 2y ago

For me, personally, I do a ton of fullstack work in JavaScript-land, but also have Python services for ML-heavy needs, and it’s nice to define one schema that at its root is still SQL while generating query clients for multiple languages.