Slonik: A PostgreSQL client with strict types, detailed logging, and assertions(github.com)
github.com
Slonik: A PostgreSQL client with strict types, detailed logging, and assertions
https://github.com/gajus/slonik
8 comments
Its really not that complicated.. each except either handles an error or rethrows it for the outer except to handle it.
Maybe a one liner comment would help, but exaggerating as if the code is some horrifying monstrosity is not helpful IMO. It just smells of elitism and makes the code seem more unapproachable than it really is.
Maybe a one liner comment would help, but exaggerating as if the code is some horrifying monstrosity is not helpful IMO. It just smells of elitism and makes the code seem more unapproachable than it really is.
It's not really that complicated it's just error bubbling with a lack of comments. Definitely worth a refactor into an exception map or something instead of this nested mess though. I've seen worse pass lazy code review honestly (working with scientists you really see some crazy code).
Anyone know how this compares to porsager's "postgres" lib?
https://github.com/porsager/postgres
https://github.com/porsager/postgres
Have to say I'm pretty happy with TypeORM[0], this is going to have to be really good to pry that from my hands.
Slonik does have a wonderfully smaller API surface and I sure do like writing SQL manually and getting to take advantage of various lower level benefits (ex. postgres JSON operations) without too much fuss/work arounds, but TypeORM also lets you drop to raw (but parametrized) SQL fairly quickly, and it's query builder is actually pretty good...
[0]: https://typeorm.io/
Slonik does have a wonderfully smaller API surface and I sure do like writing SQL manually and getting to take advantage of various lower level benefits (ex. postgres JSON operations) without too much fuss/work arounds, but TypeORM also lets you drop to raw (but parametrized) SQL fairly quickly, and it's query builder is actually pretty good...
[0]: https://typeorm.io/
Great library, gets out of the way while preventing common mistakes. makes my work easier. Thank you gajus!!!
As a memory aid, Slonik means "little elephant" in Russian, and probably other Slavic languages.
Reminds me of Rybka.
http://rybkachess.com/
http://rybkachess.com/
Great to see this package here. We have been using slonik for over a year now with few regrets. I am not a fan of query builders. Query builders work for simple inserts or updates. For really complex queries, nothing beats writing SQL inside of the sql template tag.
Another nice thing about slonik is that it is built on top of https://github.com/brianc/node-postgres. One gets all the benefit of node-pg with the nicer dev experience of slonik.
Another nice thing about slonik is that it is built on top of https://github.com/brianc/node-postgres. One gets all the benefit of node-pg with the nicer dev experience of slonik.
Any pitfalls that you encountered?
I'm trying to decide between this, or writing my own helpers around https://github.com/felixfbecker/node-sql-template-strings.
Also, have you found anything the solves typechecking of embedded expressions inside the SQL template?
For example, Webstorm will help you autocomplete your SQL, but you can still type:
I'm trying to decide between this, or writing my own helpers around https://github.com/felixfbecker/node-sql-template-strings.
Also, have you found anything the solves typechecking of embedded expressions inside the SQL template?
For example, Webstorm will help you autocomplete your SQL, but you can still type:
sql`SELECT * FROM foo WHERE barInt = ${bazStr}`
slonik has no knowledge of the pg schema, so it cannot help with this.
You may want to look at something like https://github.com/adelsz/pgtyped. The downside is that dynamic queries are more challenging.
We have been looking at moving over to pgtyped, but it will be a hard transition because we do a fair amount of building up queries at runtime.
You may want to look at something like https://github.com/adelsz/pgtyped. The downside is that dynamic queries are more challenging.
We have been looking at moving over to pgtyped, but it will be a hard transition because we do a fair amount of building up queries at runtime.
Last few years I've been using a similar workflow with something like https://www.npmjs.com/package/pg-template-tag in combination with `pg`. I'm never going back to ORMs and query builders.
Any reason you chose that over node-sql-template-strings [1], which looks very similar?
[1] https://github.com/felixfbecker/node-sql-template-strings
[1] https://github.com/felixfbecker/node-sql-template-strings
The template tag solution is cute but dangerous if you can accidentally leave off the `SQL` tag and the query still works.
Ideally the system would require you to use the tag and prohibit a plain ol string.
Ideally the system would require you to use the tag and prohibit a plain ol string.
TypeScript compiler will error on this.
It does require you to use the tag.
There are however gems like this in the source:
https://github.com/gajus/slonik/blob/master/src/routines/exe...
You can spend an hour trying to reason about the control flow of that triple try/catch alone. Bonus points if that function can recursively call itself (not sure what retryTransaction can get up to).
There may be an explanation for this horrifying code, but it should probably be right above in the form of:
To untangle that mess you'd probably have to rewrite it once just to understand it, rewrite it again to get it right, then spend a month getting the edge-cases right.
But at least afterwards a newcomer can fix a bug without endangering the multiverse.