Fork me on GitHub
#xtdb
<
2021-01-09
>
levitanong06:01:11

Hi! Is it expected behavior for :delete to leave behind a historical entry with a :crux.db/content-hash of #crux/id "0000000000000000000000000000000000000000"?

refset10:01:16

Hi :) yes that's the marker in the timeline we use to denote the termination of a validity period

levitanong12:01:01

I see. And in a situation where you :crux.tx/put two versions of a document, then :crux.tx/delete the latest one, is it also expected behavior for entity to return nil? I would've expected entity to return the latest version of the document.

Toyam Cox02:01:26

The second version replaces the former version

Toyam Cox02:01:37

delete marks the key as not having a current document.

✔️ 3
Toyam Cox02:01:00

So your timeline looks like this: a... b..... NONE.... (entity shows the latest).

levitanong03:01:34

Ah I was under the impression that :delete only invalidated a particular version, rather than marking the entire document as deleted. Such that :deleteing the latest version is like an undo. Is this usecase unsupported?

refset11:01:58

It's not directly handled as a first-class API operation, but you can use entity-history to find the N-1 version and put it once again (and use match for the active version to ensure consistency, if needed)

levitanong14:01:57

Ahh, I was hoping for a way to actually alter the history, as I'm attempting to use the entity-history as a sort of attendance log that can be changed in the event of a mistake. That said, I suppose I can add some additional metadata that ignores certain entries when printing that log

refset18:01:28

Oh I see, yes it would need to be recorded in some other way, like you suggest. Can you tell me what the domain is that you're working on? Where possible it's usually simplest to model domain-level time concepts as regulate attributes+values, since Crux today doesn't provide a rich query capability across valid time history.

levitanong19:01:46

Sorry for the late reply. Oh this is just a silly attendance tracking thing. Though I am looking into Crux for storing GTFS data that can change over time (because transport networks change over time)

refset22:01:29

Neat, I hadn't read about GTFS before - definitely an interesting domain for running some big temporal graph queries! I would be very glad to discuss it sometime if you want to bounce some ideas around 🙂