Fork me on GitHub

Is there a real difference between delete vs put a doc with the same entity but no attributes? The advantage of the latter is that you can do metadata like stuff (who deleted this) as part of the doc itself


the latter may still join against values which reference its entity id; the former won't


also, match will treat the two differently - whether that's a 'real difference' depends on your use case 🙂


ah, that's true. I've commited to the entity IDs having no semantic meaning whatsoever so that's mitigated. Match is a tougher problem since ideally you'd probably want it to ignore metadata, although maybe it'd be helpful to match on metadata sometimes.. but there's always tx fns


I guess it could be a performance issue to join on things that would otherwise be skipped with delete?


or I could still do the metadata doc, AND the delete op in the same tx.. cake and eat it too?

👍 1
🙂 1
🍰 1

Wasn't there an issue about put and delete to the same entity in the same tx? Or was that evict


that was evict, yep


does evict have any implications for tx log replay? eg. if there's a tx function that does different things based on what is found at the time... or are the end results of the tx fn stored in the tx log?


then I don't understand, isn't indexing done after something is already in the tx log


and if the tx fn results are stored in the log, then how does that work


ah, I see what you mean, my mistake - it's a nuance around what actually goes on the tx-log when it comes to tx-fns we assume that the arguments to a transaction function could potentially have personally-identifiable information in, so when a tx-fn is invoked, we split the invocation up into the function to be invoked and the arguments. the arguments go into a document in the doc-store, and a reference to the arg-doc included in the entry on the tx-log (not dissimilar to normal put operations) it's the content of this arguments doc that's then replaced with the result of the tx-fn invocation


replaced by the first node that happens to index the tx?


replaced by every node that indexes the tx concurrently - this is why it's important that tx-fns are deterministic, so that the subsequent updates are idempotent


so when replaying a tx log at some later time, a new node would directly use the resulting tx instead of running the tx fn?


yep, correct


ok, thanks for the explanation. makes sense


my pleasure 🙂