Clojurians Log v2

hmm https://github.com/xtdb/xtdb/issues/4472 this functionality will be removed? bummer, so the only way to get the nested subquery data with proper types will be to use transit? I think the NEST_* is a very good feature, and my library relies on it heavily to pull nested entries, but it needs the JSON-LD stuff so timestamps etc don't just come through as strings

more "cancelled due to lack of interest" - we asked the community regularly through the EA what they were using, everyone we've had use the JSON-LD (literally only a couple of people who ever said anything about it) has gone on to use Transit (which serves the same aim you describe, albeit in a more stable way and with libraries in most major languages so people don't have to roll their own), so given our limited resources we leaned towards that. what's the Transit support like in C? I'm guessing non-existent 😕

SMOP... simple matter of programming

but just that if you ask for a binary representation and the engine crashes if you don't set the transit format, that is imo bad default behaviour

right, let's get that one on the backlog 🙂 will see if we can get the JDBC driver to replicate that behaviour

fwiw, at least https://github.com/impossibl/pgjdbc-ng driver can be made to use binary format

I tried fixing, I think this should be enough https://github.com/xtdb/xtdb/pull/4541

cheers @tatut, merged 😊

can confirm that time now comes through in json ld when running latest nightly

@jarohen figured out the difference, if I ask for resultFormat=1 (binary) the I get the JSON-LD variant of the nested data JSON... if I ask for resultFormat=0 (text) I get the timestamp as a simple string

aha 😊 OOI, is that a useful distinction for you? we've also made Transit available there (if you SET fallback_output_format='transit' in the connection - currently an internal implementation detail but could consider making it public) if that'd be more helpful

well, I think the JSON-LD format would be nice, but it doesn't seem to work for all types

If I insert a LocalTime, the query fails with:

11:10:59 | DEBUG xtdb.pgwire | Interpreting SQL:  insert into orders records {_id: 1, customer_id: 1, placed: TIMESTAMP '2025-06-12 15:35:22', ordertime: TIME '20:12:45', orderdate: DATE '1981-04-08'};
11:11:07 | DEBUG xtdb.pgwire | Interpreting SQL:  select nest_one(select * from orders o where o.customer_id=customer._id) as last_order from customer where _id < $1 order by _id ASC
11:11:07 | DEBUG xtdb.pgwire | error processing message:  unknown type: java.time.LocalTime
xtdb.error.Incorrect: unknown type: java.time.LocalTime
	at xtdb.AnySerde.toJsonElement(JsonSerde.kt:166)
	at xtdb.AnySerde.toJsonElement(JsonSerde.kt:148)
	at xtdb.AnySerde.serialize(JsonSerde.kt:174)
	at kotlinx.serialization.json.internal.StreamingJsonEncoder.encodeSerializableValue(StreamingJsonEncoder.kt:259)
	at kotlinx.serialization.json.internal.JsonStreamsKt.encodeByWriter(JsonStreams.kt:99)
	at kotlinx.serialization.json.Json.encodeToString(Json.kt:125)
	at xtdb.JsonSerde.encode(JsonSerde.kt:321)
	at xtdb.pgwire.types$fn__10089$fn__10331.invoke(types.clj:693)
	at xtdb.pgwire$cmd_exec_query$fn__27608$fn__27611.invoke(pgwire.clj:1186)
	at clojure.core$mapv$fn__8565.invoke(core.clj:7059)
	at clojure.lang.PersistentVector.reduce(PersistentVector.java:418)
	at clojure.core$reduce.invokeStatic(core.clj:6964)
	at clojure.core$mapv.invokeStatic(core.clj:7050)
	at clojure.core$mapv.invoke(core.clj:7050)
	at xtdb.pgwire$cmd_exec_query$fn__27608.invoke(pgwire.clj:1180)
...

I don't want to write both JSON-LD and Transit handlers in my library 😅

xt:timestamp and xt:date works in JSON-LD, but time doesn't

except if I do insert into foo records {_id: 1, data: ['my', 'things']}; that data seems to be returned as _text (oid: 1009)

ah, so it detects that everything is of the same type, so it will make a text array... if I add a number in with the strings, I'm back to JSON

but why is psql seeing different JSON (without @type and @value annotations) than my libpq code, psql sees json that has a timestamp as a simple string

shouldn't be, in theory - to confirm, what's the data/query that led to that?

(thanks for exercising libpq btw - I think you're the first person we've had trying XTDB from C 🙂)

here's 1 difference

no problem, had some time... I'm not really using libpq in any production thing, but I started to use that for my swixt library instead of the http api

I'm expecting the json-ld, because that allows me to convert the data into the right prolog terms instead of just strings... just curious why psql isn't seeing the same (or is it just formatting it to hide that)

https://github.com/xtdb/xtdb/issues/4528 for this one

thanks @tatut 🙏 could you turn XT debug logging on (`XTDB_LOGGING_LEVEL_PGWIRE=debug`) and it should log the errant query?

(more generally, we're back from XT25 today, so I'll get these carded up)

how do I set that in the docker invocation?

or can I set it while it's running

-e ... if you're using Docker

runtime - hmm, yeah, we could put in a function to change it dynamically 🤔

here's the full log when dbeaver tries connecting

aha, duplicate columns - yep, this is one for a card 🙏