3 ms·

Yeah, so I don't agree with much of this. I usually end up rolling my own abstraction layer on top of SQL in whatever language I'm using, and have been doing s

by codr7 3y ago

Yeah, so I don't agree with much of this. I usually end up rolling my own abstraction layer on top of SQL in whatever language I'm using, and have been doing so for 25 years now; it's not that much code if you only write what you need. First of all, it makes the same class=table assumption that's hurting every ORM I've come across. This only scratches the surface of what a relational database can do. You want support for records that may contain arbitrary number of columns from different tables on some level. Secondly, while I agree that migrations should be first class, I also want support for them (and DDL) in the host language. My last project was based on event sourcing; which meant that to be able to replay the event stream reliably, migrations had to create events. First class queries is another thing that I've never seen out in the wild. It's not that complicated to add a composable layer on top of SQL to generate arbitrary queries. And while there are certainly differences between databases and SQL dialects, I've been involved in 2Mloc projects that ran on several different databases with a thin compatibility layer in between. It's perfectly doable.

hparadiz 3y ago
My abstraction layer over SQL turned into an ORM over time. Same pattern.
karmakaze 3y ago
> First class queries is another thing that I've never seen out in the wild. It's not that complicated to add a composable layer on top of SQL to generate arbitrary queries. I'm interpreting the post as wanting to do just that with static typing and calling it an ORM. From TFA > I want a query language that’s better than SQL. Specifically, it has to be 1) composable, 2) statically typed and with 3) a sane syntax. I want sum types. I want a statically-typed way of constructing composable queries that follow SQL rather than reinvent a different thing. It doesn't have to be the same syntax but it has to be the same structuring. I started writing one[0] and stopped before doing all the boilerplate code generation, having moved on from the JVM ecosystem for the time being. One thing it does is treat most things like sets so we don't end up with N+1 queries. Another trick it uses is collapsing constant expressions via an expression evaluation library[1]. [0] https://github.com/karmakaze/safeql https://github.com/karmakaze/safeql [1] https://github.com/karmakaze/moja https://github.com/karmakaze/moja
- ndriscoll 3y ago
  The Scala ecosystem has a few ways to do composable type-safe query building, e.g. Slick[0] or more recently Quill[1]. I believe both also have ways to do compile-time string interpolation (e.g. sql"""select * from users where id = ${user.id}""".as[User]) which generate prepared statements (I know Slick does prepared statements. Quill appears to have a similar interpolator). [0] https://scala-slick.org/ https://scala-slick.org/ [1] https://zio.dev/zio-quill/ https://zio.dev/zio-quill/

by codr7 3y ago

hparadiz 3y ago

My abstraction layer over SQL turned into an ORM over time. Same pattern.

karmakaze 3y ago

> First class queries is another thing that I've never seen out in the wild. It's not that complicated to add a composable layer on top of SQL to generate arbitrary queries. I'm interpreting the post as wanting to do just that with static typing and calling it an ORM. From TFA > I want a query language that’s better than SQL. Specifically, it has to be 1) composable, 2) statically typed and with 3) a sane syntax. I want sum types. I want a statically-typed way of constructing composable queries that follow SQL rather than reinvent a different thing. It doesn't have to be the same syntax but it has to be the same structuring. I started writing one[0] and stopped before doing all the boilerplate code generation, having moved on from the JVM ecosystem for the time being. One thing it does is treat most things like sets so we don't end up with N+1 queries. Another trick it uses is collapsing constant expressions via an expression evaluation library[1]. [0] https://github.com/karmakaze/safeql https://github.com/karmakaze/safeql [1] https://github.com/karmakaze/moja https://github.com/karmakaze/moja

ndriscoll 3y ago
The Scala ecosystem has a few ways to do composable type-safe query building, e.g. Slick[0] or more recently Quill[1]. I believe both also have ways to do compile-time string interpolation (e.g. sql"""select * from users where id = ${user.id}""".as[User]) which generate prepared statements (I know Slick does prepared statements. Quill appears to have a similar interpolator). [0] https://scala-slick.org/ https://scala-slick.org/ [1] https://zio.dev/zio-quill/ https://zio.dev/zio-quill/