xtdb

2025-10-22T15:19:28.906549Z

is there no IN for XTDB2? I'm writing a batched Pathom resolver and I'm a bit wary of writing (or (= my/id #uuid "....") ...) for perhaps 200 IDs at a time.

refset 2025-11-04T21:33:52.687479Z

Thanks for sharing your solution, I think that's the right approach here. XTQL definitely isn't deprecated - the tutorial is just a little out of date (😅) - but evolving it is not our focus right now compared with shipping a high quality SQL experience. That said, feedback like this is welcome 🙏

seancorfield 2025-10-22T15:58:23.087119Z

I would expect IN to work in SQL for XTDB2...?

➕ 1
2025-10-22T16:03:43.994869Z

yep I am using it in SQL

2025-10-22T16:13:04.133459Z

In SQL for sure. I'm using XTQL and it's not in the docs. But it's also not "standard lib" exactly. I wonder if contains in clojure style will work.

seancorfield 2025-10-22T18:46:21.136169Z

Why not use SQL for queries? HoneySQL supports the temporal stuff for XTDB and next.jdbc is explicitly tested against XTDB in CI.

2025-10-22T19:47:01.769319Z

deps count and ease. XTQL is pleasant to work with and nothing else in this project has anything to do with SQL. but perhaps I should switch gears.

seancorfield 2025-10-22T19:54:37.898819Z

SQL is the primary API Juxt are supporting at this point.

2025-10-22T19:56:28.183749Z

that's a fair point. looking at the (deprecated?) Learn XTQL Today, there are rel inline relations; perhaps unifying a relation containing the input values is the way to do it. that's how it would work in Datalog, I suppose.

2025-10-22T19:58:25.582539Z

I tried it and that does work, FWIW.

💡 2