Fork me on GitHub
#announcements
<
2024-01-22
>
mpenet08:01:06

Initial (and early) release of https://github.com/mpenet/pact - a library allowing you to generate json-schema from specs

๐Ÿ‘€ 3
โค๏ธ 8
๐ŸŽ‰ 2
ikitommi12:01:21

๐Ÿ‘ I comment, from the readme: > There are a few libraries in the same area for clojure, namely spec-tools and malli. > In most cases they focus on openapi/swagger rather than json-schema, which sits at a lower level and now is the foundation for openapi (it wasnโ€™t always the case). both libraries have pure JSON Schema too, e.g. spec-tools.json-schema and malli.json-schema namespaces.

mpenet12:01:38

my bad! I ll change that

๐Ÿ‘ 1
pez11:01:02

Say hello to Seatbelt, https://github.com/PEZ/seatbelt, a test runner for #joyride scripts (and VS Code extensions in general) that supports running in CI as well as be used as a watcher while you are hacking VS Code. Itโ€™s super easy to take for a spin (you do not even need VS Code, believe it or not). Itโ€™s new as a standalone project, but versions of it have been in use for quite a while, end-to-end testing Calva and Joyride. Since it is a Joyride script itself, it can be used for unit testing of Joyride scripts. Feedback entirely welcome. Thanks in advance! ๐Ÿ™ โค๏ธ joyride

๐Ÿ‘ 7
1
joyride 6
kennytilton13:01:45

โž• the name!

๐Ÿ˜‚ 2
igrishaev18:01:46

There is an early release of https://github.com/igrishaev/pg2, a Postgres driver for Clojure (JDBC-free, written from scratch). The previous https://github.com/igrishaev/pg project is now archived. I made some benchmarks comparing PG2 and Next.JDBC: https://grishaev.me/en/pg2-bench-1

๐Ÿ‘ 26
๐ŸŽ‰ 5
1
Cora (she/her)18:01:57

I'd love to know your thoughts on why this library benchmarks faster than next.jdbc

igrishaev18:01:17

Well, maybe because of having less abstractions. The Java code of PG2 is pretty dull and straightforward

Cora (she/her)19:01:26

do you convert straight off the wire into clojure data types?

igrishaev19:01:16

I read a byte buffer from a socket, then parse it according to the docs. Then there is a state machine that composes the final result from these messages.

1
seancorfield19:01:10

There's definitely some overhead producing ResultSet objects and then converting them to hash maps in next.jdbc so I'm not surprised the query side is faster here. Nice work! I guess that's why insert/update is about equal: omitting all that post-processing. I'll try to remember to link to this from the next.jdbc docs as an alternative for PG users to try out.

1
๐Ÿ‘ 2
respatialized14:01:38

I'd be interested in how this approach compares with and/or can be extended to columnar data access patterns like https://arrow.apache.org/adbc/current/driver/postgresql.html. I'm not sure if analytics is a primary use case for PG2 but something similar that's closer to the wire format would be useful for anyone using stuff like tech.ml.dataset for data work in Clojure.

respatialized14:01:38

(at first glance it seems like anything more efficient would depend on upstream changes in Postgres itself)

Cora (she/her)14:01:13

I wonder how much analytical queries would really benefit from removing little bits of overhead like this, it feels like high fruit on the tree to pick. maybe I'm not dealing with the right datasets or queries to really understand that, though

Cora (she/her)14:01:08

I mean, removing overhead at the edges like this instead of internally

respatialized14:01:13

DuckDB's postgres scanner might be close to the state of the art for the performance ceiling of columnar/analytical queries against a Postgres DB without internal changes to Postgres itself. Similar to PG2, it uses a binary transfer format directly. https://duckdb.org/2022/09/30/postgres-scanner.html

Cora (she/her)14:01:56

DuckDB is so good, this doesn't surprise me

โž• 1