Hacker News Reader

Comment by alpinisme | Hacker News Reader

The point is end to end type safety. Whether that is worth the tradeoff of losing direct developer access to the db primitives is another question.

View on HN

SQL is end to end type safe.

Isn’t sql weakly typed? Or does this depend on the engine?

SQLite is the only one I know of that doesn’t enforce types by default, but I don’t know what the SQL spec requires.

No it is strongly typed, there is no accident that all PL extensions to the base query language have such a Ada/Pascal similarity.

Additional DML has plenty of options to enforce rules that keep data consistency.

While they make the life harder to delete/update/insert items in specific sequences, they can save the day on bad queries.

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

You get a type error from the database.

As far as I can tell, some engines will implicitly coerce types so “7” = 7

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.

Which end? This moves one end to reach frontend code

Only backend to database. This is talking about typesafe from database - backend - frontend.

Yes, and that’s an architectural choice you’re making.

Instead of using all the consistencies provided in the database process - including types, but also date/time, constraints, transactions, triggers etc. you are exiting the system and losing all guarantees.

This system also doesn’t solve that problem.

You can write raw sql and use the "describe" clause in script, and then generate code with the result. This gives full db-backend-frontend type safety with raw sql queries

They might mean static typing in queries.

I agree with end to end type safety but that needs more details to sell what problem its solving. Folks dont buy it for itself

Reply on news.ycombinator.com