4 ms·

As a database person, I think most ORMs lack the ability to run complex queries. Sure, for a simple OLTP system, you might just need a few simple joins. But if

As a database person, I think most ORMs lack the ability to run complex queries. Sure, for a simple OLTP system, you might just need a few simple joins. But if you store valuable data (otherwise why store it), you will eventually want to ask questions about it. So this ORM positively surprised me, as you can still just use SQL and get a JS function generated from it. To bridge object-to-relational mapping, Oracle has an interesting concept called "JSON duality views". Don't dismiss it because it is Oracle, I think the concept is brilliant. The translation from relational to JSON happens in the database, and it also allows you to send an updated JSON back and the DB will automatically run the necessary DML operations. A good example is here: https://oracle-base.com/articles/23c/json-relational-duality-views-23c https://oracle-base.com/articles/23c/json-relational-duality...

matharmin 3y ago
The JSON duality views is quite a neat idea. You can get something similar in SQLite with normal views and triggers using JSON1 functions, but it would be a lot of effort to create those triggers manually.
mattgreenrocks 3y ago
This is a really nice idea!
mst 3y ago
You can definitely tell when an ORM was written by people who actually -like- databases rather than people who want to not have to think about them. perl's DBIx::Class ORM had a rule from day one of "if you can't get the exact same SQL you'd've written by hand, that's either a bug or a missing feature" and close to two decades on people who've moved to other languages still regularly tell me they miss that aesthetic.
- paulddraper 3y ago
  That's the philosophy of JOOQ. Which is a way to write SQL in Java. (with type safety too)
- SJC_Hacker 3y ago
  That is my biggest gripe with Mongo. As much as SQL requires a totally different way of thinking, as a query language ts simply unmatched for its expressive power, except by maybe Datalog. Mongo just doesn't feel like that. Every example I have seen is simply "KV lookup". No discussion of things like range based queries, or how data relates to each other. Yes of course these things are possible, but it requires writing a imperative query. Seems like it encourages people to be lazy and duplicate data everywhere, which results in a poor data model.
randomdata 3y ago
> Don't dismiss it because it is Oracle Why would we dismiss the number one feature we have been asking database vendors to implement for the past 20 years just because Oracle happens to be among those vendors?

matharmin 3y ago

The JSON duality views is quite a neat idea. You can get something similar in SQLite with normal views and triggers using JSON1 functions, but it would be a lot of effort to create those triggers manually.

mattgreenrocks 3y ago

This is a really nice idea!

mst 3y ago

You can definitely tell when an ORM was written by people who actually -like- databases rather than people who want to not have to think about them. perl's DBIx::Class ORM had a rule from day one of "if you can't get the exact same SQL you'd've written by hand, that's either a bug or a missing feature" and close to two decades on people who've moved to other languages still regularly tell me they miss that aesthetic.

paulddraper 3y ago
That's the philosophy of JOOQ. Which is a way to write SQL in Java. (with type safety too)
SJC_Hacker 3y ago
That is my biggest gripe with Mongo. As much as SQL requires a totally different way of thinking, as a query language ts simply unmatched for its expressive power, except by maybe Datalog. Mongo just doesn't feel like that. Every example I have seen is simply "KV lookup". No discussion of things like range based queries, or how data relates to each other. Yes of course these things are possible, but it requires writing a imperative query. Seems like it encourages people to be lazy and duplicate data everywhere, which results in a poor data model.

randomdata 3y ago

> Don't dismiss it because it is Oracle Why would we dismiss the number one feature we have been asking database vendors to implement for the past 20 years just because Oracle happens to be among those vendors?