4 ms·

I don't really share your opinion here (and, likely, the supporting ones about how to use ORMs). But simply disagreeing here would waste both of our time, so I

I don't really share your opinion here (and, likely, the supporting ones about how to use ORMs). But simply disagreeing here would waste both of our time, so I thought I'd ask you about specifics instead. Can you give me some short links to examples demonstrating the upsides you see there? Which off-the-shelve ORMs are good ones in your opinion? Since my take is likely based on my biases: I really haven't made good experiences with a couple of off-the-shelf ORMs, especially Hibernate and Entity Framework, both in green-field and "entrenched before I joined the project" scenarios. Both models I've seen (generate a DB schema from code annotations and generating code from some magic tool you run against your DB schema) seem really ill-advised to me (from an architectural standpoint) if the respective code is supposed to form the core of an architectural model. And if it doesn't, I can't really see the benefit in avoiding code duplication unless supporting a wide range of database vendors is a requirement. That said, I also never worked on CRUD style applications and all projects I worked on didn't need to work with multiple database vendors. And I've certainly seen the "oops, you wrote an ORM!" effect, but the thing that irks me there was that it wasn't necessary (at least in my opinion). I'd also readily agree on schema migrations, but there are good non-ORM solutions for that problem, too. So, what I've seen there, as problems go, is mostly a lack of care, structure and proper process akin to every occurrence of "bad code". I'm not sure that this problem is easily solved by any solely technical solution. Do you think any of that is what made the difference in our experiences?

imtringued 4y ago
Try using GORM for Grails. You still have to specify your fetching strategy but it is so much more sane than using raw Hibernate. I don't know what people mean by code duplication. When using GORM I just use liquibase to create and update tables. The default data type mapping rules are easy enough to memorize.
- ttfkam 4y ago
  Does GORM allow the use of window functions, pivot tables, recursive queries, filtered aggregates, unnesting arrays, splitting a string into rows, or lateral joins? I mean without an explicit escape valve to write raw SQL queries, which means you're bypassing the ORM anyway.
  - gunnarmorling 4y ago
    It seems your requirements mostly center around OLAP use cases? In that case, an ORM isn't the right tool to begin with, i.e. lacking support for these things doesn't diminish the value proposition of ORMs, which lies elsewhere (mapping results to managed object graphs in OLTP applications, tracking changes to the same, and synching them efficiently back to the DB). For OLAP, object mapping typically doesn't provide much value.
    - ttfkam 4y ago
      Nope, I'm mostly OLTP. But even mostly OLTP systems need dashboards, even if they're read from periodically refreshed materialized views. I also use things like lateral unnest of arrays for ordering dependent rows. Actually LATERAL shows up a lot to compute on the fly. And while everything I listed can and should be used in OLAP, OLTP has uses for these items too.

imtringued 4y ago

Try using GORM for Grails. You still have to specify your fetching strategy but it is so much more sane than using raw Hibernate. I don't know what people mean by code duplication. When using GORM I just use liquibase to create and update tables. The default data type mapping rules are easy enough to memorize.

ttfkam 4y ago
Does GORM allow the use of window functions, pivot tables, recursive queries, filtered aggregates, unnesting arrays, splitting a string into rows, or lateral joins? I mean without an explicit escape valve to write raw SQL queries, which means you're bypassing the ORM anyway.
- gunnarmorling 4y ago
  It seems your requirements mostly center around OLAP use cases? In that case, an ORM isn't the right tool to begin with, i.e. lacking support for these things doesn't diminish the value proposition of ORMs, which lies elsewhere (mapping results to managed object graphs in OLTP applications, tracking changes to the same, and synching them efficiently back to the DB). For OLAP, object mapping typically doesn't provide much value.
  - ttfkam 4y ago
    Nope, I'm mostly OLTP. But even mostly OLTP systems need dashboards, even if they're read from periodically refreshed materialized views. I also use things like lateral unnest of arrays for ordering dependent rows. Actually LATERAL shows up a lot to compute on the fly. And while everything I listed can and should be used in OLAP, OLTP has uses for these items too.