Fork me on GitHub

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 crux.api/entity?


Like (->> (crux/q <get entity ids>) (map first) (map crux/entity))


@benzap yes that's the standard approach.


Crux has a 'lean' core api


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.

👍 4

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.

👍 4

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 - 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


that's pretty cool thanks!


> 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-created and :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