xtdb

friedqi 2025-01-13T13:24:42.609509Z

How does v2 handle a clojure bigint? The types doc here https://docs.xtdb.com/reference/main/data-types.html indicates the largest for bigint is 64-bit signed. I need to store ethereum token amounts.

Jon Hancock 2025-01-16T05:18:04.010349Z

@taylor.jeremydavid Numeric up to 256 bit (unsigned) is critical to our needs. How long could it take to get this in v2? This quarter? this year?

refset 2025-04-22T13:09:32.171119Z

Hi @jon151 just a quick message to say that we've now implemented DECIMAL support, see https://discuss.xtdb.com/t/numeric-precision-of-xt2/540/3

refset 2025-01-16T10:14:04.929949Z

Hi @jon151 our priorities can always flex - right now this wouldn't be on our critical path ahead of GA ...but it could be. I'll DM to discuss options

refset 2025-01-13T13:33:14.727739Z

Hey @me1214 'bigint' (which is big from the legacy SQL perspective πŸ™‚) uses Apache Arrow's 64-bit int representation under the hood. Neither Arrow nor v2 currently handles anything larger natively, although we could add an extension type in future. For now it would probably be best to store such token amounts using VARBINARY

friedqi 2025-01-13T14:32:16.148519Z

Thanks. I just checked arrow docs. Looks like it supports unsigned 64 bit as well. Can we have access to that?

friedqi 2025-01-13T14:33:29.079189Z

Arrow also lists a decimal256 type. https://arrow.apache.org/docs/cpp/api/datatype.html

refset 2025-01-13T14:35:59.968809Z

We have support for NUMERIC on our backlog, which I think would be sufficient (πŸ€”) - also discussed recently on a recent forum post: https://discuss.xtdb.com/t/numeric-precision-of-xt2/540

jarohen 2025-01-13T14:21:23.675859Z

Afternoon folks - it's another release day πŸš€ 2.0.0-beta5 this time - highlights as follows: β€’ "Template-friendly SQL" - if you've ever had to battle with the amount of commas or ANDs in your dynamically-generated SQL query, this one's for you. β—¦ We've taken inspiration from Clojure's "commas-as-whitespace" and, WHERE possible (I'm sorry 😁), you can separate your predicates and projections (in the SELECT clause) with as many or as few commas as you like (yes, commas in the WHERE clause too). If you're using YeSQL or HugSQL, for example, this means you can end all of your dynamically-included predicates with a comma (even the first/last one) without worrying about syntax errors. β—¦ We've also brought some of the pipelining from XTQL into our SQL dialect - while you can obviously still use the top-level structure of standard SQL (i.e. your tooling all still works), we've also added the ability to pipeline (e.g.) aggregations. Start your query with FROM instead, then write as many WHERE, SELECT, GROUP BY etc as you like. β–ͺ︎ This removes a lot of the necessity for sub-queries in common cases - if you need multiple aggregations (e.g. for a frequency distribution), or you need to filter by the result of a window function (not possible in standard SQL), just include another SELECT clause. (examples in the 🧡) β–ͺ︎ While we still support HAVING, it's now just a WHERE that just runs after the aggregation. Some may say it always was ... but you can now write FROM foo SELECT a, COUNT(*) AS a_count WHERE a_count > 10 β€’ ~4x faster ingestion through the Postgres wire-server. While we've always (and still do) recommend batching up your inserts where possible, we've made it (much) faster in the cases where you can't, by reducing our per-transaction overhead. As always, full details in the https://github.com/xtdb/xtdb/releases/tag/v2.0.0-beta5, and let us know what you think in the usual channels πŸ™ Cheers, James & the XT Team

πŸ‘ 1
πŸš€ 6
πŸŽ… 1
jarohen 2025-01-15T14:42:20.184929Z

@stefcoetzee think I've https://github.com/xtdb/xtdb/issues/4018#issuecomment-2593043778 - when you get a mo, would you mind confirming it works your end?

Stef Coetzee 2025-01-15T17:22:05.297269Z

Thanks for taking a look at this @jarohen. Nuked .m2, followed by clj -P for a clean repo with the following deps.edn:

{:deps  {org.clojure/clojure                     {:mvn/version "1.12.0"}
         ch.qos.logback/logback-classic          {:mvn/version "1.5.15"}
         #_#_org.jetbrains.kotlin/kotlin-reflect     {:mvn/version "2.1.0"}
         #_#_org.jetbrains.kotlin/kotlin-stdlib-jdk8 {:mvn/version "2.1.0"}
         com.xtdb/xtdb-core                      {:mvn/version "2.0.0-beta5"}
         com.xtdb/xtdb-http-server               {:mvn/version "2.0.0-beta5"}}

 :aliases {:xtdb {:jvm-opts ["--add-opens=java.base/java.nio=ALL-UNNAMED"
                             "-Dio.netty.tryReflectionSetAccessible=true"]}}}
Result follows below.

Stef Coetzee 2025-01-15T17:22:32.050099Z

Stef Coetzee 2025-01-15T17:23:27.357429Z

I.e. still run into the following at the end:

Error building classpath. Could not find artifact org.jetbrains.kotlin:kotlin-reflect:jar:unspecified in central ()

jarohen 2025-01-15T17:27:45.145109Z

yep, we won't be able to fix it on beta5 I'm afraid, it's an immutable release - could you bump the XT deps to 2.0.0-SNAPSHOT (including the snapshot repo if need be)?

Stef Coetzee 2025-01-15T17:32:38.816369Z

Ah, of course!facepalm My mistake. Confirmed to be working with the following deps.edn:

{:deps  {org.clojure/clojure                     {:mvn/version "1.12.0"}
         ch.qos.logback/logback-classic          {:mvn/version "1.5.15"}
         #_#_org.jetbrains.kotlin/kotlin-reflect     {:mvn/version "2.1.0"}
         #_#_org.jetbrains.kotlin/kotlin-stdlib-jdk8 {:mvn/version "2.1.0"}
         com.xtdb/xtdb-core                      {:mvn/version "2.0.0-SNAPSHOT"}
         com.xtdb/xtdb-http-server               {:mvn/version "2.0.0-SNAPSHOT"}}

 :mvn/repos {"ossrh-snapshots" {:url ""}}

 :aliases {:xtdb {:jvm-opts ["--add-opens=java.base/java.nio=ALL-UNNAMED"
                             "-Dio.netty.tryReflectionSetAccessible=true"]}}}
Thanks @jarohen!

πŸ™‡ 1
πŸ™ 1
πŸ™Œ 1
Stef Coetzee 2025-01-14T12:44:15.033789Z

Thanks for the release, @jarohen & @taylor.jeremydavid! When updating a server repo I have running locally (not in Docker) to beta5, I had to add two dependencies:

{:deps  {org.clojure/clojure                     {:mvn/version "1.12.0"}
         ch.qos.logback/logback-classic          {:mvn/version "1.5.15"}
         org.jetbrains.kotlin/kotlin-reflect     {:mvn/version "2.1.0"} ; added for beta5
         org.jetbrains.kotlin/kotlin-stdlib-jdk8 {:mvn/version "2.1.0"} ; added for beta5
         com.xtdb/xtdb-core                      {:mvn/version "2.0.0-beta5"}
         com.xtdb/xtdb-http-server               {:mvn/version "2.0.0-beta5"}}

 :aliases {:xtdb {:jvm-opts ["--add-opens=java.base/java.nio=ALL-UNNAMED"
                             "-Dio.netty.tryReflectionSetAccessible=true"]}}}
This was to resolve these successive errors:
Error building classpath. Could not find artifact org.jetbrains.kotlin:kotlin-reflect:jar:unspecified in central ()
Error building classpath. Could not find artifact org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:unspecified in central ()
Thought I'd share in case it might be of any value. ✌️

jarohen 2025-01-14T15:17:28.018509Z

Hey @stefcoetzee πŸ‘‹ that's strange, I don't recall having to add that ourselves, I wouldn't have thought anything would work at least without stdlib, and I'm not aware we depend on reflect πŸ€” thanks for letting us know - I'm OoO today but will get the team to look into it πŸ™ https://github.com/xtdb/xtdb/issues/4018

πŸ’― 1
jarohen 2025-01-13T14:32:11.775569Z

-- standard SQL, calculate frequency distribution using sub-queries
SELECT order_count, COUNT(*) AS freq
FROM (SELECT customer, COUNT(*) AS order_count
      FROM orders
      GROUP BY customer) counts
GROUP BY order_count
ORDER BY order_count DESC

-- XT SQL
FROM orders
SELECT customer, COUNT(*) AS order_count
SELECT order_count, COUNT(*) AS freq
ORDER BY order_count DESC
NB: β€’ FROM first β€’ GROUP BY is inferred in this common case β€’ run multiple aggregations in the pipeline

jarohen 2025-01-13T14:33:42.725679Z

-- filtering by the result of a window function
SELECT _id
FROM (SELECT _id, ROW_NUMBER () OVER (PARTITION BY v ORDER BY _id) row_num
      FROM foo) subq
WHERE row_num = 0

-- XT
FROM foo
SELECT _id, ROW_NUMBER () OVER (PARTITION BY v ORDER BY _id) row_num
WHERE row_num = 0 -- N.B. WHERE applied after SELECT
SELECT _id

jarohen 2025-01-13T14:34:32.966569Z

to reiterate, standard SQL still works πŸ™‚ see the https://docs.xtdb.com/reference/main/sql/queries.html#_query_term for more details

markaddleman 2025-01-13T14:57:29.349179Z

on a vaguely related note: are navigation window functions supported?

jarohen 2025-01-13T15:16:31.852479Z

@markaddleman not just yet I'm afraid, but definitely on the backlog - any you particularly use?

markaddleman 2025-01-13T15:18:55.426789Z

all of them πŸ™‚ : first_value, last_value, lead and lag. there’s no rush on my part - i’m just curious. i don’t think xtdb can be realistic for my use case until there’s something like tx-listen so i can compute indices in real time.

πŸ‘ 1
πŸ˜… 1
jarohen 2025-01-13T15:21:56.987529Z

> i don’t think xtdb can be realistic for my use case until there’s something like tx-listen so i can compute indices in real time. interested in this one too - indeed, only this morning we were chatting to someone about incremental view maintenance. obviously a much bigger project πŸ™‚

πŸš€ 3
refset 2025-01-13T16:04:01.645129Z

I'll be running through the above changes in an Office Hours session on Thursday at 1600 UTC - for anyone who's curious and wants to say hello (or ask more questions about our numeric type support!) https://discuss.xtdb.com/t/office-hours-thursday-16th-at-1600-utc/551

markaddleman 2025-01-13T16:04:50.020429Z

So, when you’re ready to chat IVM, hit me up! I have a wish list πŸ™‚

πŸ’― 1
πŸ“ 2
☺️ 1