Would a replacement for the default crux.jdbc/->document-store be in the right direction, overriding the default JdbcDocumentStore implementation?

Interesting idea. Should be possible with some custom code. Yes that's the right area.

Ah - nice! Thanks!

A follow-up - please feel free to dismiss as I appreciate this is off-track and not a key concern. If you had to do this, where would you keep metadata about the pg-json type so that types like #insts could be parsed back appropriately when thaw-ing? I suspect that since nippy is self-sufficient and thus this was never a design concern, there’s no suggested place for this and one would need to define some custom logic+storage to go with the thaw-ing.

Hi, I would also assume that you probably need to create some custom logic for transforming EDN to JSON while supporting all of EDN and being able to transform it back again. I had that same problem not long ago when work with EDN in JavaScript. I decided for a JSON-compatible format that supports all of EDN like this: EDN

{1 :keyword #{1 2} \a}

{
  "map": [
    [1, { "key": "keyword" }],
    [{ "set": [1, 2] }, { "char": "a" }]
  ]
}

Thanks @U8ZN5EHGU - pretty interesting and useful. I’ll take a look.

[FYI update] Thanks for the tips and ideas - it was pretty quick to write the basic code for this (no preservation of the richer types). The writes are relatively perceptibly slower. Some of the aggregate counts are not matching up (sql select vis-a-vis crux/q) and I’m sure there’s something silly I’ve done. Unless this is of any interest to anyone, I’ll stop updates on this thread. [Aside background] This is an escape-hatch option to make it more palatable to my group who aren’t very sure yet of investing in the new kid crux just yet… Depending on how it is received, we may decide on spending effort on more accurate encoding <-> pg.

Hey @U06KGH6LB thanks for keep us posted on where you've gotten to. Did your code follow essentially the same pattern as the edn-data lib? It makes sense that writes will be somewhat slower due to all the extra object allocations going on, as well as nippy, but I'd be surprised if initial document ingestion alone could become a deal-breaking bottleneck for your application that couldn't be optimised in some way (e.g. via hand-tuned Java transformations), or removed entirely with a more harmonious pg integration, like you say. We'd like to assist if we can - would you mind if I DM you?

That’s great, @U899JBRPF - thanks! I’ll be very happy to talk further via DMs.