Hacker News Reader

Comment by WhitneyLand | Hacker News Reader

I don’t know why this is not getting more up votes it looks pretty cool.

At first it may seem like yet another attempt to make database access easy while really making it more complex and harder to maintain.

I haven’t tried this yet, but after reading a couple pages it looks more interesting than that. For example the fact that it relies on typescript knowledge which is already widespread, and the fact that it doesn’t require any server side technology to be installed is a huge advantage.

I’m not sure how it feels in practice, if anyone has experience with it please chime in.

View on HN

One headline is:

Focus on your data – not on complex SQL queries

Looks like just another SQL DSL trying to make you not learn SQL. TS's structural typing and plain SQL can get you far into a simpler/robust system IMO.

Also, the "introspection" part of Prisma seems very crippled, Postgres has so many useful features for writing application code that it seems wasteful to just treat it as dumb data store.

Just stop the anti-ORM bs. Most applications need simple select queries, and often want to walk the obejct / relation graph. Prism looks awesome, and has great TS support. If you want to concatenate sql for each frikking query, be my guest. I have better things to do with my time, such as responding to this kind of stuff.

For "small" and "large" queries, just use the ORM. For "complex" queries, just use SQL.

> Postgres has so many useful features for writing application code

Except versioning, maintainability, testability, source control, migration, or just about 80% of what an application developers expects from the thing that runs their code.

I mean, I really really love the idea of stored procedures and triggers, it's so much more elegant than putting all the code in some Node app and just doing read-modify-write cycles into the DB, but until DBs get their ass together wrt being a properly useable platform to run code on, it's not gonna happen.

You can use things like Flyway or other tools that track schemas and migrations in source control quite easily.

I find the process of writing database access functions annoying, and for the most part, arbitrary and repetitive. ORM functionality that bakes types/accessors, migrations, graphQL, and even infrastructure into your codebase is where it’s at. The fact that you are writing your models once and automatically exposing them as types in any project’s language is a huge value. I don’t need the same language everywhere, but I want types that plug together without hassle.

Next generation “serverless” databases will fully abstract object mapping away. It’s tedious and arbitrary. Even indexing is relatively easy to automate. I am incredibly excited for what Apple is brewing up right now for developers.

Is Apple working on some sort of serverless/Firebase type thing?

I think they're referring to this: https://developer.apple.com/icloud/cloudkit/

It kind of flew under the radar, because it's not super clear how to use it from the landing page.

CloudKit, edge, etc

What is apple brewing?

SQL isn't type-safe, so Prisma has that over it if nothing else. There's also a lot to be said for the difficulty in composing efficient SQL queries. If this tool can do that (I would be surprised) it would be a significant advancement (yes, this would be "making you not learn SQL" in the same way C makes you "not learn assembly").

SQL is as type-safe as the DB engine allows it to be. PostgreSQL is type-safe. Extracting these types and making them available and usable in your lang-of-choice at compile time is a different problem though.

Yes, when we talk about type safety, we generally mean "compile time" type safety. Python is also "type safe" at runtime (which is to say, "it's strongly typed"), but we don't conventionally consider Python to be type-safe.

Well, all I am saying is that PostgreSQL provides you with compile-time type-safety when your write your queries.

Bringing this type information at "compile-time" into your language of choice where you embed your queries can also be done but is a harder problem. There is good progress in that sphere but it is still in it is infancy.

The GraphQL eco-system for example, has this figured out using code generators. A similar thing can be done with DBs.

That depends on who you generally talk with. Dynamic typing/static typing are orthogonal to eg weak/strong typing and other type system features, that's estabilished terminology.

Nothing in your post contradicts mine, but you're using a contradictory tone, so I'm confused. Dynamic/static typing are indeed orthogonal to weak/strong typing; however, the OP seemed to be arguing that "SQL is typesafe because it is statically checked at runtime/JIT-compile-time" which is almost exactly the definition of "strong typing" and not generally what we mean by "type safe" (the latter typically refers to statically typed).

I think you misunderstood my point. You mentioned that "SQL isn't type-safe", which is NOT true. Any decent RDB engine allows to perform typechecking and validation of your query without executing it. This means that SQL is typesafe at compile time.

Fair enough. This is a small consolation for practitioners, especially since much SQL is often composed dynamically, and the engine can't tell you about where the composition went wrong (unlike Rust, TS, etc). Maybe if SQL had its own hygienic macro language, but I'm not sure how that would compare to libraries like Prisma.

python is type-safe if you use python3 and avoid the dynamic parts of the language using a linter.

Since it does no checking of the annotations at runtime: I don't really think this is accurate. This prints `5` for instance: https://repl.it/repls/DarkorchidFailingComputationalscience

    def do(s: int) -> str:
      return 5
    print(do("123"))

Python is duck-typed. Wrong types aren't detected until they fail to quack correctly.

If you run mypy or pyre-check on the code above, it'll give you a type error, just like a C compiler would.

Sure, but that's like saying "valgrind exists, so C has out-of-bounds checks". It doesn't. External tools have just found ways to add optional safety that the language lacks.

Hmm, in what sense is SQL not type safe where this would be type safe, though? You could still use out of date client code connected to a DB that has had its schema change, no?

The DB and the code are not packaged together so is there even such a thing as compile time type safety?

Something like this would make sure that all queries are correct per some expected schema and processes keep the expected and live schemas in sync. Such a process might be "database migrations run in the CD pipeline and nothing else changes the database". Of course there are edge cases here and there (someone will eventually need to log into a production database), but these processes go a long way toward reducing risk.

Composability and encapsulation are both somewhat lacking in SQL and there are valid reasons to want to write queries in a different DSL that can be compiled to SQL.

I have been rewriting a big application with it, I would say its getting there but some features are still lacking and you start to hit them when you do more advanced stuff (long-lived transactions, aggregation, etc.). But the team is working very fast and I am super confident we will have everything by GA (most of the issues are tracked). For example we didn't have access to foreign keys last week and they added that in like 3 days. It's a huge step forward in terms of code quality is you don't like ORM like me, but you also hate not having typing when using query builders/raw SQL.

Reply on news.ycombinator.com