5 ms·

I'm wary of the term "ORM" and in particular the idea that you'd get your SQL defined at compile, which is exactly what something like PGOcaml does, and which i

I'm wary of the term "ORM" and in particular the idea that you'd get your SQL defined at compile, which is exactly what something like PGOcaml does, and which is a bad idea if it's the only game in town. As someone who gets to write SQL fairly regularly, I'm a lot more interested in composability than anything else (I'll even trade type safety for composability if I have to pick one). I'd rather have a system to generate composable queries (hopefully in a typesafe manner) and able to use modern SQL syntax (eg, window functions), without the stuff you typically find in an ORM (identity map, magic setters, etc)

sgrove 11y ago
This has always been a big challenge for me with SQL - programmatically composing queries, filters, etc. has been 1. very difficult across the board and 2. very function-oriented rather than data-oriented. I still hold out hope for a datalog-to-sql layer, someday.
snuxoll 11y ago
This is something that really bugs me about OCaml in general. There's really no good option to do database access that doesn't involve writing raw, non-composable SQL queries. I don't need a full blown ORM, but something that makes writing type-safe (and injection-resistant) SQL queries like JOOQ would be absolutely amazing. For now I'm just sticking with Python and SQLAlchemy, as much as I love OCaml and F#.
- insulanian 11y ago
  F# doesn't fit into the rest of your comment. There are type providers and Entity Framework, both of which are very good options for DB access.
  - snuxoll 11y ago
    IFF you are using Microsoft SQL Server, sure. Any other RDBMS is a crapshoot, I've been using FsSql which works but I have to devolve into manually manipulating SQL Query strings to do anything sufficiently advanced. Technically there is SQLProvider, but it's ugly as sin (I also don't care for type providers in general, I don't need automatic code generation, I have no problem specifying my schema and not needing access to a database server just to compile my code).
    - insulanian 11y ago
      I'm using PostgreSQL with Entity Framework and running my code on Mono. It all works in production on an AWS Ubuntu instance with DB in RDS. Very happy. Edit: Forgot to mention that no Visual Studio or Windows is used in the process.
      - snuxoll 11y ago
        Entity Framework is extremely heavy and not really what I am looking for. I really just want a lightweight layer over SQL that makes query generation safe, not a full blown ORM (think JOOQ, SQLAlchemy).
        daxfohl 11y ago
        I use Dapper with F# both on Mono/Linux (test/prod) and on Windows (dev/build/test) and it works great and I've never had an OS porting issue in three years. There are extensions that make it more composable, but haven't needed them yet. Type safe solutions, in terms of using code expressions that get translated into SQL, exist too. However everywhere I look people complain about how horribly inefficient and frequently buggy the generated SQL is. This is true in LINQ, EF, Scala's SQL generator, etc. Stackoverflow obviously created Dapper for a reason. So I've thus far avoided these "too clever by half" solutions; Dapper is perfectly fine.
- wastaz 11y ago
  I actually also thought that this was a problem so I started trying to build an ORM-ish thing in F#. I havent had that much time to spend on it lately, but its in a pretty OK state as is. If you have any comments or opinions then Im open for all suggestions :) https://github.com/wastaz/hyperboliq https://github.com/wastaz/hyperboliq
daxfohl 11y ago
Indeed, it certainly needn't be #1. The recent migration to "micro-orm" such as Dapper (.Net) and Yesql (Clojure), just thin wrappers over ODBC/JDBC shows that ORMs aren't the end-all. Yes they lack composability and type safety. You could easily add composibility in the guise of something line various existing JsonQL libraries. Type safety, at some point (crossing process/network boundaries) you just have to be pragmatic and let go.

sgrove 11y ago

This has always been a big challenge for me with SQL - programmatically composing queries, filters, etc. has been 1. very difficult across the board and 2. very function-oriented rather than data-oriented. I still hold out hope for a datalog-to-sql layer, someday.

snuxoll 11y ago

This is something that really bugs me about OCaml in general. There's really no good option to do database access that doesn't involve writing raw, non-composable SQL queries. I don't need a full blown ORM, but something that makes writing type-safe (and injection-resistant) SQL queries like JOOQ would be absolutely amazing. For now I'm just sticking with Python and SQLAlchemy, as much as I love OCaml and F#.

insulanian 11y ago
F# doesn't fit into the rest of your comment. There are type providers and Entity Framework, both of which are very good options for DB access.
- snuxoll 11y ago
  IFF you are using Microsoft SQL Server, sure. Any other RDBMS is a crapshoot, I've been using FsSql which works but I have to devolve into manually manipulating SQL Query strings to do anything sufficiently advanced. Technically there is SQLProvider, but it's ugly as sin (I also don't care for type providers in general, I don't need automatic code generation, I have no problem specifying my schema and not needing access to a database server just to compile my code).
  - insulanian 11y ago
    I'm using PostgreSQL with Entity Framework and running my code on Mono. It all works in production on an AWS Ubuntu instance with DB in RDS. Very happy. Edit: Forgot to mention that no Visual Studio or Windows is used in the process.
    - snuxoll 11y ago
      Entity Framework is extremely heavy and not really what I am looking for. I really just want a lightweight layer over SQL that makes query generation safe, not a full blown ORM (think JOOQ, SQLAlchemy).
      - daxfohl 11y ago
        I use Dapper with F# both on Mono/Linux (test/prod) and on Windows (dev/build/test) and it works great and I've never had an OS porting issue in three years. There are extensions that make it more composable, but haven't needed them yet. Type safe solutions, in terms of using code expressions that get translated into SQL, exist too. However everywhere I look people complain about how horribly inefficient and frequently buggy the generated SQL is. This is true in LINQ, EF, Scala's SQL generator, etc. Stackoverflow obviously created Dapper for a reason. So I've thus far avoided these "too clever by half" solutions; Dapper is perfectly fine.
wastaz 11y ago
I actually also thought that this was a problem so I started trying to build an ORM-ish thing in F#. I havent had that much time to spend on it lately, but its in a pretty OK state as is. If you have any comments or opinions then Im open for all suggestions :) https://github.com/wastaz/hyperboliq https://github.com/wastaz/hyperboliq

daxfohl 11y ago

Indeed, it certainly needn't be #1. The recent migration to "micro-orm" such as Dapper (.Net) and Yesql (Clojure), just thin wrappers over ODBC/JDBC shows that ORMs aren't the end-all. Yes they lack composability and type safety. You could easily add composibility in the guise of something line various existing JsonQL libraries. Type safety, at some point (crossing process/network boundaries) you just have to be pragmatic and let go.