Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rethinking Database Programming

acadia.engineering

Post reply on HN
Print view View original

151–160 of 167 posts

Re: Rethinking Database Programming

#151

Post by 1-more »

ModernMech wrote: post #32
happyraul wrote: post #24

Earlier 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?

None of the forks really have the same design goals as Elm though, so if you're compiling Elm code into JS you're probably using the Elm 0.19.2 compiler, not a fork.

- There's an outside chance you're doing Zokka to allow for custom package repos (I think that's the only difference).

- You may be using the Lamdera compiler to use Set and Dict natively with your custom types.

If you're doing something other than compile Elm to JS for UIs, you may in fact be using one of the actual forks.

Re: Rethinking Database Programming

#152

Post by 1-more »

happyraul wrote: post #35
ModernMech wrote: post #32

Earlier quoted context omitted.

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 think it's fair to say there are other ways to interpret what happened with Elm. What if Evan stopped working on it because he needed to make a living and working on Elm wasn't going to achieve that? In that case, if working on Acadia will earn him a a living, it seems reasonable to believe he will keep working on it.

"Stop" is no longer the right word. Elm had a release on July 6th. The counter has reset.

Re: Rethinking Database Programming

#153

Post by ninkendo »

pjmlp wrote: post #139
zem wrote: post #133

Earlier quoted context omitted.

I like the idea behind stored procedures, but the ergonomics of developing and maintaining them are not great. if they could be made to look like a library of code sitting in a directory somewhere, and transparently compiled and imported by the database but still workable with using external tools like git, I think they would feel a lot less strange.

The ergonomics are the same as any language, when using IDEs with the SQL vendors plugins, instead of vi and CLI admin for queries.

> when using IDEs with the SQL vendors plugins

Do these plugins mean you don't get to store them in git? You're just going to open up the developer studio and YOLO a change to the stored procedure, live in production? Because the whole argument is that the way we do version control, code review, bisecting, single-artifact deployment, etc is generally at odds with how stored procedures work. Saying "but my IDE has a good plugin" solves maybe 1/100th of the problem.

Some answers to doing stored procedures in a version control system that I've seen:

- Put everything in a migrations directory, and every time you change the stored procedure, introduce a new migration that completely rewrites it. (Merge conflicts are hell with this, plus all the massive amount of waste it generates in the checked-out tree)

- Put the stored procedures in a directory as normal code and then "sync" them to the database at runtime (with all the massive foot-guns this entails, trying to detect if they've changed versus what's in the database, etc)

- Eschewing stored procedures in favor of using prepared statements and having your ORM figure out when to use them

There may be others but I think they're all going to look like some form of one of the above.

Re: Rethinking Database Programming

#154

Post by speed_spread »

LandR wrote: post #30
happyraul wrote: post #29

Earlier quoted context omitted.

From the homepage https://acadia.engineering/ : | Not an Object-Relational Mapping (ORM).

I dont see how this isn't just an ORM (like Entity Framework in dot net land).

It's an external contract first ORM. It brings strict typing but doesn't go into object persistence management.

It's similar to what OpenAPI/Swagger does for REST.

Being contract first means that both SQL and corresponding application data bindings get generated from the same universal spec.

Cons :

- It can make using platform-specific features harder than in plain SQL.

- It makes database app code and SQL statements dependent on the whims of evolving generators libraries. Which is not a problem 'per se' but imposes an oversight cost, especially if you customize said generators or develop your own.

But it brings many architectural advantages. Compared to typical ORM

- Runtime initialization time is very quick if not instant.

- Bindings can be precompiled in separate lib, only rebuilt when schema changes, making faster builds.

- Schema management, meaning versioning and migration strategy planning can be centralized. That to me is a big thing for long lived business projects with multiple deployments in varying environments.

- From the code it makes a database closer to a standard service API. There might be a parallel to make with using stored procedures as database interface.

Re: Rethinking Database Programming

#155

Post by dwohnitmok »

hombre_fatal wrote: post #148
dwohnitmok wrote: post #136

Earlier quoted context omitted.

That's not the norm that's being broken here. Most DB technologies provide a "pay for updates, if you stop paying you keep the last version you paid for" model. This is how Oracle prices its DB tech, this is how jOOQ is priced (which is probably the closest thing to Acadia), this is how MS prices its DB tech etc.

The responses to the pricing aspect of this announcement around the web disagree. I'm not saying you can't find paid software, especially from Oracle and Microsoft, but there's a different expectation for "just-a-guy announcing his project on twitter". You can see a similar mentality regarding Elm in general where the approachability of one guy had people in some sort of parasocial entitlement to the project that you…

> The responses to the pricing aspect of this announcement around the web disagree.

Which responses are you thinking of?

Re: Rethinking Database Programming

#156

Post by ltbarcly3 »

threethirtytwo wrote: post #111
ltbarcly3 wrote: post #103

Earlier quoted context omitted.

Just learn SQL. I believe all these SQL replacement layers are just because people don't like SQL and don't learn it, so they learn a training wheels version of it that will cripple their ability to grow because it's simplifications remove expressiveness that caused SQL to be more complex to begin with. Just learn SQL, it's not that hard. A lot of very very smart people put a lot of effort into it. It's very good. Th…

No. SQL is just bad. It's an old way of doing things. It's not hard but it's not good. Take this for example. Why do we have static type checking for typescript? Why do we have a build step for this? Why DON'T we have it for SQL? Why is it runtime strings? So no static checking and the only way to test if a query works is to run it? The purpose of these replacement layers is to get it all under one language. Once it'…

Runtime strings? No static checking? I think you have used mysql and think that mysql is somehow what you should expect, because you are just saying wildly incorrect things. (You don't know what you're talking about)

Re: Rethinking Database Programming

#157

Post by moljac024 »

mike_hearn wrote: post #143
bazoom42 wrote: post #141

Earlier quoted context omitted.

What happens if a query compares a string to a number?

You get a type error from the database.

But when do you get that type error?

This is the important bit.

You get it after the app is deployed, the query is ran and a result is expected.

When do I get a type error from my language if it's statically typed? That's right, before I even deploy.

Re: Rethinking Database Programming

#158

Post by truculent »

adzm wrote: post #53
mike_hearn wrote: post #45

The 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.

The problem here is that you still have to do some pointless and tedious conversion between generated data structures and your domain data structures. Maybe with LLMs, some of that tedium goes away, but you still have to test, maintain and understand that part of the code.

Re: Rethinking Database Programming

#159

Post by threethirtytwo »

ltbarcly3 wrote: post #156
threethirtytwo wrote: post #111

Earlier quoted context omitted.

No. SQL is just bad. It's an old way of doing things. It's not hard but it's not good. Take this for example. Why do we have static type checking for typescript? Why do we have a build step for this? Why DON'T we have it for SQL? Why is it runtime strings? So no static checking and the only way to test if a query works is to run it? The purpose of these replacement layers is to get it all under one language. Once it'…

Runtime strings? No static checking? I think you have used mysql and think that mysql is somehow what you should expect, because you are just saying wildly incorrect things. (You don't know what you're talking about)

i do. default way of doing things is sending a string from server to database.

You don't know what you're talking about.

Re: Rethinking Database Programming

#160

Post by threethirtytwo »

pjmlp wrote: post #144
threethirtytwo wrote: post #111

Earlier quoted context omitted.

No. SQL is just bad. It's an old way of doing things. It's not hard but it's not good. Take this for example. Why do we have static type checking for typescript? Why do we have a build step for this? Why DON'T we have it for SQL? Why is it runtime strings? So no static checking and the only way to test if a query works is to run it? The purpose of these replacement layers is to get it all under one language. Once it'…

Only true when avoiding stored procedures.

Yeah. Most systems avoid stored procedures imo. They way to go imo is to use stored procedures for everything, but the standard pattern has stored procedures as some sort of secondary thing.

Either way the types of the stored procedures do not statically mesh well with the types of the application server. So there's a lot of syncing issues here that can only be caught at runtime.

Post reply on HN