Not currently, although I definitely see the merits and I added it as an idea on our backlog a while ago 🙂 In the meantime I suspect the DataScript implementation could be fairly easily adapted and used for Crux in userland https://github.com/tonsky/datascript/commit/5bc0b3e6090152d6cfd2726d3d92ddc821185cf7

There was also a Zulip thread where this was discussed once: https://juxt-oss.zulipchat.com/#narrow/stream/194466-crux/topic/Organizing.20Crux.20results

this might be of some use, if you hadn't already created your own version

(defn q2
  "Decorate a supplied `q` call with return maps
  Caveats:
   - no error handling, simply reverts to default behaviour (return tuples)
   - no enforcing of keys/syms/strs types
   - does not ensure keys are unique
   - not usable with `crux.api/open-q`
   - a built-in implementation could probably be more efficient"
  [qfn {:keys [find keys syms strs] :as query} & args]
  (let [ks (or keys syms strs)]
    (cond->> (apply qfn query args)
      (and (vector? ks)
           (= (count ks)
              (count find)))
      (map (partial zipmap ks)))))

;; e.g.
(q2 (partial crux/q (crux/db (crux-node)))
    '{:find [e v]
      :keys [:ent :val]
      :where [[e :crux.db/id v]]})
;; => [{:ent 1 :val 1}]

We have just added it to master so it will be in the next release 🙂 https://github.com/juxt/crux/pull/1407

I think I’ve found it. Had to search github for db-spec in files named config.edn.

Spoke too soon. Still not quite there.

Hey 🙂 we only use otj-pg-embedded for testing - I don't know if it's feasible to use it in production without missing some critical features (e.g. backup/restore). What is your motivation behind wanting to use an embedded Postgres?

I don’t want to use an embedded Postgres.

I’m just following the guide…

…here https://opencrux.com/reference/jdbc.html#db-spec

where it says > Each of these also require an additional dependency to pull in the relevant JDBC driver - see the Crux JDBC https://github.com/juxt/crux/blob/master/crux-jdbc/project.clj for our latest dependencies.

The only postgresql-related dependency was the OpenTable library.

I got it. Also pushed a PR to the docs. Not sure that’s how it should be documented, but figured a first pass at it would be better than nothing. https://github.com/juxt/crux/pull/1403

Ahh, I see, yes you're perfectly correct about all that (sorry it wasn't explained!), and thanks for the PR 🙂

Hey @U01GXCWSRMW - thanks for the PR 🙂 I'd prefer that we fix this in the project.clj though - I suspect what's happened is that someone's changed the project.clj to be suitable for dev without realising that the docs point to it

Makes sense, but would that require scaffolding (setting up and tearing down a PG instance) to then run the tests?

It would, but the test dependencies are handled independently in crux-test's project.clj. In crux-jdbc they're marked as provided dependencies, so they'll only be included automatically at dev-time

In short, let's update the dep there to the main Postgres dep - if need be, we can include the pg-embedded dep in the dev profile so that it's still included when developing crux-jdbc (although the dev advice is to run the project from the root of the repo, which already includes the embedded dep)

I'll push a commit through now - thanks 🙂

Yeah. I saw that as well. 😄

I tested by replacing the dep, spinning up a second instance, and hey, there was my original data still there! I couldn't just read the database directly, it's opaque to me

@U050V1N74: I fell victim to this as well! I suspect you can safely close https://github.com/juxt/crux/issues/1364 and blame the dep

aaaaah! 💡

I could not repro that one 😄

thanks for letting me know!

haha, sorry about that :) thanks for your effort!

ah, no worries - just glad you got to the bottom of it 🙂