Fork me on GitHub
#crux
<
2019-10-20
>
benzap13:10:30

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?

benzap13:10:19

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

jonpither17:10:06

@benzap yes that's the standard approach.

jonpither17:10:36

Crux has a 'lean' core api

benzap17:10:51

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

jonpither17:10:12

The entities are locally available owing to the way Crux works, so it shouldn't be an issue.

👍 1
jjttjj17:10:09

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?

jonpither18:10:54

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

👍 1
jjttjj19:10:11

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

danielneal08:10:32

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

jjttjj14:10:52

that's pretty cool thanks!

benzap20:10:35

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

benzap21:10:42

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