Hey I think you just need to add the driver as a dep, as per how the page says: "Each of these also require an additional dependency to pull in the relevant JDBC driver - see the XTDB JDBC project.clj for our latest dependencies."

There's a hyperlink on that project.clj text

I tried putting most of those dependencies into the deps.edn as well with the same result

Do I need to require the relevant namespaces as well?

Shouldn't need to require it, hmm

Can there be a difference between the way the dependencies are used in a leiningen project?

*imported

OK, I updated my deps.edn to:

{:paths ["src"]
 :deps {org.clojure/clojure {:mvn/version "1.11.1"}
        org.clojure/tools.logging {:mvn/version "1.2.4"}
        com.xtdb/xtdb-core {:mvn/version "1.21.0"}
        com.xtdb/xtdb-jdbc {:mvn/version "1.21.0"}
        pro.juxt.clojars-mirrors.com.github.seancorfield/next.jdbc {:mvn/version  "1.2.674"}
        org.clojure/java.data {:mvn/version "1.0.95"}
        com.zaxxer/HikariCP {:mvn/version "3.4.5"}
        pro.juxt.clojars-mirrors.com.taoensso/nippy {:mvn/version "3.1.1-2"}
        
        org.postgresql/postgresql {:mvn/version "42.2.18"}
        com.oracle.ojdbc/ojdbc8 {:mvn/version  "19.3.0.0"}
        com.h2database/h2 {:mvn/version "1.4.200"}
        org.xerial/sqlite-jdbc {:mvn/version "3.28.0"}
        mysql/mysql-connector-java {:mvn/version "8.0.23"}
        com.microsoft.sqlserver/mssql-jdbc {:mvn/version "8.2.2.jre8"}}}

I replaced my deps.edn with a project.clj that looks like this:

(defproject myproject "0.1.0-SNAPSHOT"

  ;; same dependencies as  + com.xtdb/xtdb-jdbc + explicit versions

  :dependencies [[org.clojure/clojure "1.11.1"]
                 [org.clojure/tools.logging "1.2.4"]
                 [com.xtdb/xtdb-core "1.21.0"]
                 [com.xtdb/xtdb-jdbc "1.21.0"]
                 [pro.juxt.clojars-mirrors.com.github.seancorfield/next.jdbc "1.2.674"]
                 [org.clojure/java.data "1.0.95"]
                 [com.zaxxer/HikariCP "3.4.5"]
                 [pro.juxt.clojars-mirrors.com.taoensso/nippy "3.1.1-2"]

                 ;; Sample driver dependencies
                 [org.postgresql/postgresql "42.2.18"]
                 [com.oracle.ojdbc/ojdbc8 "19.3.0.0"]
                 [com.h2database/h2 "1.4.200"]
                 [org.xerial/sqlite-jdbc "3.28.0"]
                 [mysql/mysql-connector-java "8.0.23"]
                 [com.microsoft.sqlserver/mssql-jdbc "8.2.2.jre8"]])

Execution error (SQLException) at java.sql.DriverManager/getDriver (DriverManager.java:300).
No suitable driver

Which JVM? There are various working examples of good Postgres config floating around, e.g. https://github.com/xtdb/xtdb/blob/ffb5d00efde9e147f9daaef39973f5310c339aab/bench/src/xtdb/bench.clj#L291 and Biff

actually, I managed to track down the culprit

(import java.sql.DriverManager)
(DriverManager/getDriver "")
Execution error (SQLException) at java.sql.DriverManager/getDriver (DriverManager.java:300).
No suitable driver

the jdbcUrl was wrong

(DriverManager/getDriver "jdbc:")
#object[org.postgresql.Driver 0x1b80a6d8 "org.postgresql.Driver@1b80a6d8"]

Ah, frustrating :) glad to hear though

there are some additional errors now, e.g. password field missing

I guess the db-spec config will need some additional fields

ok, looks like it needs both :user and :password in the :db-spec config

if :user is missing, it seems to use my unix user name by default…

I’ll figure out the smallest set of dependencies one needs to get this running and will post this here later for reference

@U899JBRPF thank you for looking into this for me

I think you would do a delete operation, and have the delete operation's valid time be the time at which you'd like the document to become invalidated.

Oh I see, that is something I will try it out. I do want to see the entity at a previous version, would I be able to see that? I basically would like one or more recent transactions against that entity

You can use xtdb.api/entity-history to get the previous versions of a document, or pass in a previous valid time/tx time to xtdb.api/db and then run queries etc as normal

So you are basically saying I need to do that filtering in user code? I was trying to get some help from xtdb's built in functions...I might need to dig more into how end valid time works

it's possible I'm misunderstanding what you're trying to do. could you share a hypothetical example, E.g. a query you'd like to be able to run?

Yes sure, say I have an entity with attr x = 5 valid as of 2021. At some point something happens on the first of Jan 2022 and my attr turns to x = 10 (valid for the whole 2022). However in March 2022 something else happens. Now the attr for 2022 is not valid anymore and I want to see attr x = 5 every time I query:grin:😇

OK, in that case you could do a put operation for the doc with x = 5 and with a start valid time of March 2022

to be complete, three put operations, with start valid times of jan 2021, Jan 2022, and March 2022 respectively.

and if (as of jan 2022) you wanted x = 10 to only be valid through 2022, the second put would have 2023 as the end valid time.

I see thank you yeah, I was trying to set valid time "after the fact" for x = 10 but what you are saying also makes sense ... I guess if we could do that we could avoid a query (for the past value)

Ah I see what you mean. yeah, no way to avoid having to look up the old value.

OK thanks for confirming and helping Jacob