This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (2)
- # babashka (1)
- # bangalore-clj (1)
- # beginners (5)
- # cider (16)
- # clojure (125)
- # clojure-spec (3)
- # clojure-uk (5)
- # clojurescript (27)
- # cursive (46)
- # data-science (3)
- # dirac (2)
- # emacs (11)
- # fulcro (2)
- # graphql (4)
- # luminus (2)
- # nrepl (1)
- # pathom (15)
- # re-frame (1)
- # reagent (52)
- # shadow-cljs (149)
- # sql (11)
- # tools-deps (11)
- # xtdb (14)
When attempting to return a list of entities, is it common practise to perform a query to get the list of entity ids with
crux.api/q, and then generate the list from
Interesting, thanks @jonpither. My only concern is making several queries, but I suppose there's some magic happening behind the scenes that i'm not aware of
The entities are locally available owing to the way Crux works, so it shouldn't be an issue.
When using the
crux.kv.memdb.MemKv backend, the
:db-dir in the crux config corresponds to a "unique name" rather than an actual directory right? Everything associated with it is totally destroyed when the DB is closed right?
@jjttjj There is a persist on close option which is used to persist the state of the store when you close it. Otherwise yes it's ephemeral and db-dir isn't used.
Is there a way to get a crux node when the reference to it has been lost? (When I need to
.close it but have accidently blown up the reference in the repl). Particularly for RocksKv backend
This might be a good use case for objection - https://github.com/riverford/objection you can
obj/register all your stateful objects like this node and can then
obj/status to find it again even if you lose the repl ref
> Note that all Crux Datalog queries run using a point-in-time view of the database which means the query capabilities and patterns presented in this section are not aware of valid times or transaction times.
Does this mean that I need to maintain my own
:date-created value if I want to sort my entities by the date they were created?
Building on what i'm saying, I assumed that Bitemporality meant that the crux database kept a history of transactions, and the use-case presented was to go back in time to perform queries on the database.
However, I also thought this meant that you didn't need to maintain your own
:date-updated document fields, since these could be implicitly determined from the transaction-time ie.
:date-created --> some query function that retrieves the first transaction time since entity creation
:date-updated --> some query function that retrieves the last transaction time since entity creation