Clojurians Log v2
xtdb
We're live! 🚀 Thank you all so much for your help throughout the early access - whether that's been feeding back on use cases, or helping out with bugfixes and repros - it's all very much appreciated gratitude
congrats on the release!
congrats! hoping to migrate to it soon.
Congrats! Amazing work.
nice to see a GA release, there were some system defined tables/views (like xt.txs ) are those documented in the docs?
also, was the HTTP API removed?
@tatut I'm curious what you're using Prolog + XTDB to do??
perhaps something some day... I just like tinkering, I don't have an application that I use this for (yet)
Ha perfect, that is where the most interesting things seem to come from - someone following their curiosity and tinkering.
my library now talks directly over pg wire protocol, no HTTP API anymore... the pg write protocol is pretty nice actually
HTTP server wasn't removed, that still exists, but we removed the Clojure HTTP client in favour of a client that talked to the Postgres wire-server instead:
https://clojurians.slack.com/archives/CG3AM2F7V/p1747053150534499
then removed in beta9: https://clojurians.slack.com/archives/CG3AM2F7V/p1749038429117629?thread_ts=1749038011.857829&cid=CG3AM2F7V
I didn't see it in the docs, my prolog library is using it https://github.com/tatut/swixt
but I guess I should migrate that to use ODBC instead
If you're using the HTTP API directly, that shouldn't need to change; if you're only using it via the Clojure API, should be able to seamlessly migrate to xtdb.api/client rather than xtdb.client/open-client , then it's the same xtdb.api functions
ok, is there 2.0.0 docs for the HTTP API?
iirc, there was some openapi definition in the docs previously, but I can't find it now
there's an open-api still but openly it's definitely a second-class citizen to the PG wire server, we're focusing our development effort on the latter
found the openapi.yaml on github, I can look from there
noticed that if you accidentally use " quotation in records, the keys will not be recorder
xtdb=> insert into customer records {_id: 3, address: {country: "FI", street: "Street 7", postal: "123456"}, name: "Some Name"};
INSERT 0 0
xtdb=> select * from customer where _id = 3;
_id | address | name
-----+---------+------
3 | {} |
(1 row)' quotation, it worksshould there be some error or warning? (using psql as client)
yeah, this one catches people out a lot (including me 😅) but is SQL standard - it's expecting to find columns with those names. we should be returning a warning through the Postgres connection?
yes, it makes sense when you stop to think about it, but perhaps it should indeed issue a warning as those columns don't exist
yep - that the warning isn't getting through is something for us to look into 🙂
Kubernetes deployments are likely to be overkill for a lot of teams
agreed, yep - that's why it's not a hard reqmt for XT 🙂
I was just going through the docs looking for a simple prod deployment guide and I figured I give some feedback 🙂 Might be nice to have something in between a local dev with a single container and a kubernetes + kafka cluster.. if it is possible, I remember it was in 1.x, can’t easily tell by the 2.x docs
ahh, got it - thanks 🙂
Hey @dimitar.ouzounoff would a basic https://docs.k3s.io/ config + guide be a useful "in between" for your needs? It would still need external object storage (s3, MinIO etc.)
No, it wouldn’t
the v.1 had a benefit of a very simple (as in simple vs easy) deployment; there is nothing simple about kubernetes even if it is convenient sometimes
what sort of thing would you be expecting, out of interest? we obviously can't cater for every type of prod deployment on every potential cloud provider, and openly I'd hoped 'simple Docker image' on one end and 'kubernetes' on the other would cover enough cases (or, at least, be adaptable for enough cases) - but it seems I've missed a middle ground? 🙂
Perhaps you're just hoping to use the in-process JAR again, like v1? You can still do that, but we don't recommend it as the default pattern because down the road people often then expect to be able to easily provision and scale the app compute independently of the massive disk and memory requirements for the db compute. Redeploying the app becomes slow, etc. etc.
v1 and datomic are simple enough imo; I guess I can try the in-process JAR again
more tire kicking, I'm trying to call XTDB via the libpq C api, and I guess you can't have parameters that would be deduced by the backend... if I don't pass those in I get
running query: select * from customer where _id > $1 (argc: 1)
Query failed: ERROR: class java.nio.DirectByteBuffer cannot be cast to class java.lang.Number (java.nio.DirectByteBuffer and java.lang.Number are in module java.base of loader 'bootstrap')
DETAIL: {"category":"cognitect.anomalies\/incorrect","code":"xtdb.expression\/class-cast-exception","message":"class java.nio.DirectByteBuffer cannot be cast to class java.lang.Number (java.nio.DirectByteBuffer and java.lang.Number are in module java.base of loader 'bootstrap')"}comparing to a string field works, even without passing type info
yep, we do generally need to be given type info, more than Postgres, because of the polymorphic nature of XT
that said, if you can provide us with a repro there that'd be great - we should be giving a better error message 🙂
PQexecParams(conn, sql, argc, NULL, query_args, NULL, NULL, 1);
so I'm just passing in the values in query_args as char* without any other info
I'll try with adding a some type info... I guess the type OIDs are stable
looks like int8 is 20 in both xt and pg17 (and timestamp is 1114)
yep, we've taken our type OIDs from Postgres
have you got an example of the query you've sent and the args?
the above select * from customer where _id > $1 and the 1 args being just "1" cstring