Clojurians Log v2

Hey @dmays 👋 We've no plans currently to support XTQL outside of Clojure - we previously supported it through a JSON representation but it turned out pretty unwieldy in most non-Clojure client languages, and most have some form of data-oriented SQL generation. > Is the XTQL very different from the v1 Datalog? Yes, it's quite different from v1 Datalog - mainly because v2 has tables (for the SQL compatibility), so we needed to make some relatively significant changes, which then reduced the user familiarity sufficiently that we saw it as a good opportunity to re-think it a little 🙂 > Is there a timeline for v2 to be considered stable? Regarding timelines, we're currently working with a number of design partners who are developing applications against XT2 - once we have a few of those in production, we'll likely cut a stable release. If you'd like it before that, then please do get in touch about being a design partner and we can help you through issues you might encounter > With a Kotlin driver, XTDB v2 can't run locally within an offline first Kotlin application correct, it still needs to run on a server? If you're running a JVM you can run XT2 in-process, but depending on the type of device you're running on it might not be the best experience - we've not optimised it in any way for low-resource environments, let's say. Cheers 🙂

Thanks! I'd been a bit under the impression that the lack of tables were an advantage in V1, aligning a bit with many of the advantages of Datomic. With tables now involved, what benefits did v1 offer that are now going away or diminished? Schema on read? Is data still an EAV like structure? Thanks, sorry I'm admittedly not advanced enough in these topics to really be asking, but have been interested in the v1 benefits for a while now and am trying to feel out if those perceived benefits no longer fit the new model.

We technically impose a little more of a schema decision earlier in asking for a table, but tbh most of the v1 use cases we saw had most documents containing a 'document-type' key anyway - the recommendation is now to make this the table name instead, and for that we can now offer the XT2 SQL support, opening up the SQL tooling ecosystem. Apart from that, the documents themselves are still schemaless - even within a table you can vary the columns in each document, and the types of the values of any individual column, same as v1. The data itself is now stored in bespoke Apache Arrow columnar files, so we have a lot more control over storing it in a format that's amenable to querying. And not at all, dw - these are very nuanced considerations 🙂

Thanks!!

yw 🙇 and if you want to chat in more detail about a specific use-case, do give @taylor.jeremydavid or me a shout 🙂

Hey @dmays if you're curious about XTDB with Elixir, see https://discuss.xtdb.com/t/elixir-ecto-support/490/3?u=refset We've also been looking at surfacing the edn-XTQL within SQL (so you can send it over JDBC / Ecto as an embedded string), but it's WIP

Cool thanks!