xtdb

itaied 2025-02-20T09:30:59.010039Z

hey all, i've been playing a bit with assert and i was wondering if xtdb has something like SQL check constraint? correct me if i'm wrong, but the assert happens before the data is committed, so i can verify constraints that are related to the existing data (current state) like uniqueness, foreign key... but if i want to verify constraints that are related only to the entity (regardless of the current state) i have to do that in the application server? or is there an equivalent to pg "check" constraints or trigger functions?

jarohen 2025-02-20T09:33:21.439609Z

you can also run ASSERT after your DML to check post-conditions - XTDB runs transactions in a single thread (strict serializable, the highest isolation level) so you're guaranteed that no other writes will affect your data until after it commits

jarohen 2025-02-20T09:34:26.789969Z

we don't yet have the ability to store these in the database I'm afraid - the more people tell us they want them, the sooner it'll happen, so thanks for letting us know πŸ™‚

itaied 2025-02-20T09:45:21.870289Z

ok i understand, i'm giving it a try the constraints that i can execute are limited to the functions and predicates XTDB support, correct?

jarohen 2025-02-20T09:47:38.116659Z

yep, but you also get access to subqueries etc too, so you can check data in other tables - ASSERT is often used as ASSERT [NOT] EXISTS (SELECT ...) to achieve foreign-key behaviour

jarohen 2025-02-20T09:48:47.407079Z

or, equivalently, ASSERT ? IN (SELECT _id FROM table)

itaied 2025-02-20T10:01:05.600409Z

cool

itaied 2025-02-20T10:01:42.173139Z

i'm missing something tho i have tried validating the length of name to be less than 10 the assertion fails but the data is written, what am i doing wrong?

jarohen 2025-02-20T10:12:37.304399Z

try an explicit transaction? BEGIN beforehand

πŸ™Œ 1
itaied 2025-02-20T10:16:05.226819Z

yup, the explicit tx did work why is it requried? i thought that xtdb wraps the expressions in txs

jarohen 2025-02-20T10:26:42.420259Z

sorry, that's my bad, it splits the statements before it wraps each individual one in a transaction

πŸ‘ 1
refset 2025-02-20T17:14:08.543229Z

Prompted by discussions in the above Reddit thread (thanks everyone!) I've published some additional Clojure examples in https://github.com/xtdb/driver-examples/tree/main/clojure/dev - including a sample https://www.jooq.org/sakila data set and a key snippet that allows next.jdbc to traverse the schema (but not including the many-to-many join tables):

(tap> (jdbc/execute! conn ["select * from inventory"]
          {:schema-opts {:pk "_id"}})) ;; infer all FKs for datafy/nav usage
any other requests? πŸ™‚

seancorfield 2025-02-20T18:02:13.967729Z

How are the m2m tables / relationships structured (since you imply next.jdbc cannot auto-nav them)?

refset 2025-02-20T22:59:40.339569Z

The original Postgres schema for those tables looks like: https://github.com/jOOQ/sakila/blob/aed53ce65404eac184f4134f34239a08c464df77/postgres-sakila-db/postgres-sakila-schema.sql#L194-L198 For my XT import we derive a surrogate _id PK which is just a concatenation of the FK value pairs. Dustin and I spent some time playing with some code to infer the join tables here: https://gitlab.com/hyperfiddle/electric-fiddle/-/blob/f79b98d3f58ef025896bc8a8d800334abeda567c/src/dustingetz/xtdb/xtdb.cljc#L51-100

refset 2025-02-21T09:20:13.723469Z

> any other requests? oh, HoneySQL examples(!)