In v1 is there a way to accumulate transactions into a speculative/virtual DB using with-tx - in the sense of being able to e.g. iteratively accumulate something like (swap! speculative-db insert new) in a loop or pipeline, rather than rebuilding (xt/with-tx db ops) every time
hey @k.neo20030816 👋 there isn't, I'm afraid - but with-tx is cheap to re-call, so it should be relatively straightforward to create a loop of it, if I've understood your use case correctly?
Fair enough, I ended up doing that anyway. I think I was after a way to treat the with-tx result as if it was a DB instance
Is there a blog article or something that explains the pivot to SQL first?
I actually had a little chat with Jeremy already, but we haven't been able to move forward from that, partially because at the time I was basically trying to push for clojure AND xtdb at once- bit of a stretch. Now, while most of our stack is still python and I have postponed the clojure mission a bit (except for build tooling with babashka), I just today encountered significant evidence (again) that we have a problem that screams for xtdb. One of our devs is kind of advocating building time travel on our own and I have a gut feeling that that's a bad idea. So, I might indeed benefit from another little chat in the near future - maybe this time together with our CTO. Having an expert explain it to him might be more effective than just me.
Also I think the more official-looking support on various cloud providers might make this look less intimidating
Not specifically - it's been more of an incremental journey tbh. The main theme has been reach and interoperability - we've gotten so much value from being able to use industry-standard tooling, libraries and drivers that we would have had to reproduce ourselves if we'd continued down the Datalog path. Similarly, our paying clients were asking for it - because even though the developers often preferred Datalog, they didn't exist in isolation, and it was much harder to convince (e.g.) data analysts in the rest of the business. I think (although I'm obv biased 🙂) that we've ended up at the best of both worlds - the interoperability of SQL, but also with the ability to supply XTQL seamlessly within an SQL query - even as the whole query, if that's your preference.
Cool, thanks:) yeah, the interop point makes total sense, SQL is probably here to stay. Will that interoperability extend to metabase at some point?
I think the addition of "tables" in XTDB v2 really kind of submarined Datalog because by extending it to support tables (and some other XTDB-specific stuff), it stopped being Datalog as most people know it. It's cool that XTQL exists but it's really its own thing now, not really Datalog. Would you say that's fair @jarohen?
@aaronrebmann What doesn't work right now with Metabase and XTDB v2 when used as a PostgreSQL DB?
It might work now, last time I tried was like 6m ago and it seemed to be incompatible. To be fair though, I didn't try very hard, I expected that it would be as smooth as with postgres and when I found that it wasn't, I put that on hold
@aaronrebmann we've done a lot of work on that in the 2.2 release line - if you want to give it a go, our nightlies (e.g. docker tag nightly-20260422) are pretty stable
Sweet, that's really great news, thanks:tada: That'll help me shilling xtdb at work:sweat_smile:
our pleasure 🙂 > That'll help me shilling xtdb at work 😅 funnily enough, I think that's exactly why we went for SQL 😄 and do let us know if we can help out