I wonder what a nontrivial multi-table query with joins look like in Acadia?
Rethinking Database Programming
61–70 of 167 posts
Re: Rethinking Database Programming
#62Earlier quoted context omitted.
On the other hand, with Elm there was no correlation between adoption and funding for development. With Acadia, he's trying a different funding model, so that might mean better support for both Acadia and Elm.
The Elm project forked into a bunch of different Elms because Evan basically abandoned / killed it. Then he got more interested with this project. What’s to say that won’t happen again?
I would make the larger point that I do not like my software to depend on any software with a bus factor of one that I can't control. Elm had this problem and Acadia has it too.
Re: Rethinking Database Programming
#63The issue with defining schemas in a non-SQL programming language is they always lag behind what the underlying database can do. Sure, your ORM-like framework can define basics like primary keys and maybe uniqueness constraints, but can it define partitioning schemes, compression methods or more advanced constraints? Look at all the features supported here: https://www.postgresql.org/docs/current/sql-createtable.html…
A core idea of the relational model is to seperate the logical model from the physical layer including optimizations, indexes etc.
So it makes sense to only expose the logical model at the ORM layer.
The problem comes if you want to define the database schema through the ORM layer, rather than just represet it.
Re: Rethinking Database Programming
#64The issue with defining schemas in a non-SQL programming language is they always lag behind what the underlying database can do. Sure, your ORM-like framework can define basics like primary keys and maybe uniqueness constraints, but can it define partitioning schemes, compression methods or more advanced constraints? Look at all the features supported here: https://www.postgresql.org/docs/current/sql-createtable.html…
A core idea of the relational model is to seperate the logical model from the physical layer including optimizations, indexes etc. So it makes sense to only expose the logical model at the ORM layer. The problem comes if you want to define the database schema through the ORM layer, rather than just represet it.
Isn't SQL already a logical abstraction language over a "physical layer"? I'm not updating indexes or deciding when to flush or fiddling with MVCC when I write SQL
Re: Rethinking Database Programming
#65The issue with defining schemas in a non-SQL programming language is they always lag behind what the underlying database can do. Sure, your ORM-like framework can define basics like primary keys and maybe uniqueness constraints, but can it define partitioning schemes, compression methods or more advanced constraints? Look at all the features supported here: https://www.postgresql.org/docs/current/sql-createtable.html…
Agreed with you here. In my experience the best solutions go the opposite way, and parse the SQL in ways that can be used from the application.
https://sqlc.dev/ does this for me. Its been nice!
Re: Rethinking Database Programming
#66Earlier quoted context omitted.
SQL is a horrible language. I’d gladly program in something composable like Elm.
As a programming language? Sure. As a way to work with relational data? It may be my favorite "language" across all domains because of the terse beauty. I am a self-taught, no CS coder but SQL is the one place where I feel like I get all the math I should know. An opinionated, possibly hot take would be to call SQL "A more elegant weapon of a civilized age".
[deleted]
Re: Rethinking Database Programming
#67I'm actually most excited about the new funding model: https://acadia.engineering/license/faq
I won't be able to use Acadia at work, and I don't have the risk tolerance to use it for personal projects, but I'm looking forward to seeing how/if this model pays the bills. Can it compete with more liberally licensed code?
Re: Rethinking Database Programming
#68Earlier quoted context omitted.
A core idea of the relational model is to seperate the logical model from the physical layer including optimizations, indexes etc. So it makes sense to only expose the logical model at the ORM layer. The problem comes if you want to define the database schema through the ORM layer, rather than just represet it.
Isn't SQL already a logical abstraction language over a "physical layer"? I'm not updating indexes or deciding when to flush or fiddling with MVCC when I write SQL
The comment mentioned partioning schemes which is defined using SQL but belongs in the physical layer. Indexes are also defined in SQL.
Re: Rethinking Database Programming
#69I'm wary of languages that seek to own the database. In particular, the claim "Coexist with SQL" seems a bit suspect given that e.g. sum types have a custom binary encoding, which likely makes them difficult to interop with from other languages. This makes the claimed interop with other languages really more of a temporary stopping point towards full Acadia adoption rather than a viable long-term equilibrium, unless…
I think, the reality is SQL being simply to old to coexist with a web app use case. All the nice things that article talks about are not possible to nicely integrate with SQL. Current development is done by either writing SQL by hand or by letting ORMs to autogenerate it. Both feel bad because of how bad SQL is. But there is no other option. I hope https://substrait.io/ will gain traction and will be supported native…
I'm curious what you meant by the web app use case and why you find SQL bad?
Re: Rethinking Database Programming
#70Earlier quoted context omitted.
I think, the reality is SQL being simply to old to coexist with a web app use case. All the nice things that article talks about are not possible to nicely integrate with SQL. Current development is done by either writing SQL by hand or by letting ORMs to autogenerate it. Both feel bad because of how bad SQL is. But there is no other option. I hope https://substrait.io/ will gain traction and will be supported native…
I'm curious what you meant by the web app use case and why you find SQL bad?
He probably is still drinking the NoSQL koolaid of 2015 :)