XT Play (try v2 online) - feedback

(UPDATE 2024-05-29: ‘Fiddle’ is now renamed ‘Play’)

A few things that have been cooked up recently:

  1. https://play.xtdb.com/ - currently supports SQL and XTQL (edn/Clojure syntax)
  2. psql -h pg.xtdb.com (which creates a fresh db each time you connect!)
  3. A new quickstart tutorial using xtsql, a python-based terminal console: Quickstart | XTDB

…so I’m opening this topic to capture ongoing feedback and ideas :slight_smile:

1 Like

Thanks for XT Fiddle, it’s great fun!

I want to try out the history API in v2 in XT Fiddle, but I’m not sure how to communicate the intent in XTQL.

Suppose one transacts the pre-populated content:

[:put-docs :docs {:xt/id 1 :foo "bar"}]

And then:

[:put-docs :docs {:xt/id 1 :foo "baz"}]

How can the history of the document with :xt/id of 1 be queried?

The From documentation’s “Temporal filters” subsection mentions :all-time. How might this be used correctly?

This returns only the most recent version:

(from :docs {:bind           [xt/id foo]
             :for-valid-time :all-time})


The UI probably needs some extra hints to guide users on this, but essentially you need to split those put-docs entries across separate transactions (otherwise the first version gets ~dropped, see also): XTDB Play

Alternatively, you could also specify distinct valid-times for the entries, e.g.:
XT Fiddle

The ‘+’ button appeared to be disabled (it renders kinda greyed out). I had executed the two transactions one after the after, but editing and running each time.

Using the ‘+’ and adding the second transaction that way worked.

Thanks Jeremy!

1 Like

it renders kinda greyed out

Thanks for the feedback, hopefully the new styling is clearer :slightly_smiling_face:

Let’s collect some interesting fiddle URLs in this thread, here’s one for starters:

1 Like

Been playing with xt fiddle a bit, and something that may add some value is being able to “elide assert failure(s)”, so that way invariants can be enforced against a query.

This fiddle demonstrates asserting a document has a different hash before attempting to put the document into the table. It’d be great to be able to have some sort of UX to “catch” the assertion failure and move onto the next transaction statement, rather than always fail.

Additionally, for the XTQL side, parens/quotations/bracket auto-encolsing makes editing queries and transactions a pain. There are many times I want to add forms, a single " character (or even ), ], }), and the editor(s) dissallow me to add those in some cases, or the editor interprets those to be appended to the end of the root form, even though I didn’t want it to go there.

1 Like

Thanks for the feedback @bnert - I’ve just opened an issue to remember to give this some thought soon! Consider UX for handling intentional tx/assertion failures without preventing successful querying · Issue #37 · xtdb/xt-fiddle · GitHub

1 Like