Clojurians Log v2

yep, this is just supported through Transit for now, the JSON was proving very unwieldy and not something we wanted to commit to. best to access it through the XT Clojure client if you can? otherwise, let us know your use case and we can figure out how best to go forward

I don’t need XTQL, just curious… my “use case” for now is just playing around and using XTDB from Prolog https://x.com/tatut/status/1823375791255650318

ooh, intriguing 👀

that's neat ☺️ 🙇

the point is to provide a “candidate” record and it would make a query that fetches all rows that look like the candidate

I see 🙂 any plans for how you might introduce joins, say? (it's been way too long since my brain was in Prolog mode 😅)

yes, this was literally just a couple of hours of hacking

so very young, next up is NEST_MANY/ONE at least

heh, yep - we've spent way too many hours writing those SQL queries by hand ourselves 😅

me too

my first throught would be to model it as a regular attributes, with from/to field dates, no need for time travel in that case

Hey @dave554 in general you should avoid trying to use valid time to represent anything other than the timeline about when a 'fact' is learned to be true (i.e. the state of an entity over time as best-known, and as defined by a particular document version). Concepts like "account status timeline" or "service window" are best represented within facts, like the response above describes. For v2 we are planning to add SQL range types that will make this kind of userspace modelling around time easier

Thanks!

like a bigdecimal with a scale of 2 if I want exact numbers only (like money)

hey @tatut you can see the currently supported scalar types here: https://docs.xtdb.com/reference/main/data-types.html#_scalar_types generally speaking, all typing reflects Arrow types first and foremost, and then considers ISO SQL semantics, and then finally Postgres semantics Arrow does actually have DECIMAL128 and DECIMAL256 as https://arrow.apache.org/docs/cpp/api/datatype.html, but v2 doesn't do anything with those currently, but it could, and then potentially map them to the equivalent of Postgres' DECIMAL type what domain type are you actually hoping to model? is it money?

I mean the JSON API specifiically

as JSON only has the 1 number type, and I didn’t see any JSON LD types for different number types

so if I pass in 4.20 in a JSON payload, what type is that in the database?

so I guess if one wanted an exact decimal number, using bigint and fixed point math is the way to go

for example, if I do via the API: {"txOps": [{"sql": "INSERT INTO foo (_id, n1, n2, n3) VALUES (1, $1, $2, $3)", "argRows": [[4.2, 100, 999999999999999999]]}]}

what will the n1, n2, n3 values be internally?

ah, sorry I missed that bit from my answer - the JSON LD typing support has not been implemented comprehensively yet, but you can see the current subset here: https://github.com/xtdb/xtdb/blob/0c0010e9f860197230ecbd43a3de0e6aa25b4ac7/api/src/main/kotlin/xtdb/JsonSerde.kt#L60-L70 I think we can add the other types relatively easily but it will be a low priority task for us to finish until someone files a specific requests 🙂 (new issues welcome!) JSON numbers will be coerced to Longs (`FLOAT` according to the scalar types table), but if that fails then Doubles, looking at https://github.com/xtdb/xtdb/blob/0c0010e9f860197230ecbd43a3de0e6aa25b4ac7/api/src/main/kotlin/xtdb/JsonSerde.kt#L87

thanks

I don’t have a real use case yet, just “kicking the tires” out of curiosity

but money is something that I’ve very often had to deal with in most enterprise apps

so usually important to have a precise number type

thanks, the feedback and input is appreciate - hope you've been having fun!