I really like the unique approach of the annotated SQL files and can definitely see some use cases where it would be good to declutter the SQL from the code. For me personally, I'd be hesitant to add another build tool to my already bloated toolchain. Could create a special Babel-style "import" type that automatically transforms your code (JIT)? It could remove some of the friction in adoption (for Babel users at lea…
Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres
71–80 of 90 posts
Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres
#72I really like the unique approach of the annotated SQL files and can definitely see some use cases where it would be good to declutter the SQL from the code. For me personally, I'd be hesitant to add another build tool to my already bloated toolchain. Could create a special Babel-style "import" type that automatically transforms your code (JIT)? It could remove some of the friction in adoption (for Babel users at lea…
I wonder if the JIT compiling will work asynchronously - from the readme it's getting the types from the live database schema.
Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres
#73Earlier quoted context omitted.
Zapatos author here. Yes, it does. But for most of what you’d use an ORM for, you probably won’t need custom queries.
Hey I’m not sure this is the best venue, but I’m trying to make the case for getting my org off of sequelize, and your library is right in line with my goals. The hardest sell is going to be publicly visible test coverage. Would you welcome a dedicated effort from an early adopter to introduce tests?
Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres
#74Earlier quoted context omitted.
Zapatos can generate the hairy JSON stuff for you, including lateral joins that are equivalent to your example query, which would be: const result = await db.select(‘user’, db.all, { lateral: { posts: db.select(‘post’, { userId: db.parent(‘id’) }) } }).run(pool); And result will have the structure you asked for, and be automatically typed as such. (Sorry, can’t manage helpful indentation from my phone). See: https://…
I just don't get why people write queries like that in a convoluted way which is hard to decipher and possibly optimize with so many noises whose knowledge becomes useless on the next language/framework of choice than a straight forward SQL whose knowledge can live for decades.
Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres
#75Earlier quoted context omitted.
See https://typeorm.io/#/
I mean no disrespect to the TypeORM author(s), but I was burned several times by unexpected behavior that resulted in serious data integrity issues. I would caution that anyone adopting this library test any usage heavily, especially anything to do with relations
Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres
#76Earlier quoted context omitted.
ORMs like Diesel are definitely very useful. The problem I have with them is that their ORM abstraction often leaks. Fixing these abstraction leaks is a hard problem [1]. Ofc, there has been attempts to reconcile relational DBs with OOP like languages, but they are not very popular. [2] PgTyped and some similar libs try to solve a simpler problem (typing static queries) and can be used to build more complex solutions…
I may just not have enough context on the issue, but i've not had significant issues with SqlAlchemy's hybrid ORM/Query Builder approach.
Personally I think the problem is not that ORMs are leaky abstractions, it's that they often pretend not to be. SQLAlchemy just leaks unapologetically, if you struggle with ORM you can drop right down to using an DSL to construct SQL or just write SQL directly without feeling like you have to fight the ORM and mess with undocumented internals you shouldn't be touching.
Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres
#77Lots of comments here about similar projects in a different language, but the fact that this targets TypeScript is explicitly what makes it interesting to me. Using regular Javascript database libraries, even ones that have type definitions, require a lot of double typing. I've been relatively satisfied with TypeORM, but one thing that's been a hurdle for me to some extent is its reliance on experimental decorators,…
Opening a can of worms for sure, but the reliance on Babel in the JS community is not a good thing to me. It's another reason why I prefer TypeScript, as in TSC, not whatever equivalent babel happens to support.
Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres
#78Lots of comments here about similar projects in a different language, but the fact that this targets TypeScript is explicitly what makes it interesting to me. Using regular Javascript database libraries, even ones that have type definitions, require a lot of double typing. I've been relatively satisfied with TypeORM, but one thing that's been a hurdle for me to some extent is its reliance on experimental decorators,…
As usual for Babel, there’s a plugin for that: https://github.com/leonardfactory/babel-plugin-transform-typ...
Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres
#79Looks pretty cool. What I really want though is a library that let's me write plain SQL queries which are then mapped into nested objects in a smart way without too much manual work (I know Postgres can do JSON stuff, but the queries look pretty complicated for what little they actually do). Say `SELECT * FROM user LEFT JOIN post ON user.id = post.id` would be mapped to `[{userId: 1, name: renke1, posts: [{postId: 2,…
GrahpQL might be an answer.Though an incomplete answer at this point due to a mismatch between plain GraphQL and SQL; And the real issue is how to define and where to place a single source of truth for the schema an operations. So far we saw approaches where: - GraphQL schema is generated from SQL tables. Makes total sense for a project or a company that looks to capitalize on customers with existing databases (e.g.,…
hasura.io
Re: Show HN: PgTyped – Typesafe SQL in TypeScript and Postgres
#80Earlier quoted context omitted.
I just don't get why people write queries like that in a convoluted way which is hard to decipher and possibly optimize with so many noises whose knowledge becomes useless on the next language/framework of choice than a straight forward SQL whose knowledge can live for decades.
I’m not exactly sure what you’re getting at here. The whole point of this library is that one call = one predictable query, and the SQL it generates is certainly no more convoluted than required to produce the desired result.
If your query was meant to say,
SELECT * FROM users JOIN posts ON posts.userId = users.id
the ORM has so many unnecessary characters just to get to this straight forward SQL and you have to learn how to make sure the way you write will generate the SQL that you want that uses the proper index everytime you change framework is just something I wouldn't do.
I didn't say the SQL generated is convoluted but the way you need to write so many characters that doesn't hold a meaning is convoluted.