This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-27
Channels
- # announcements (2)
- # babashka (60)
- # beginners (73)
- # calva (23)
- # cider (2)
- # clj-kondo (19)
- # cljs-dev (31)
- # clojure (29)
- # clojure-berlin (1)
- # clojure-europe (6)
- # clojure-nl (17)
- # clojure-spec (21)
- # clojure-uk (15)
- # clojurescript (54)
- # core-async (48)
- # cursive (35)
- # datomic (12)
- # emacs (12)
- # fulcro (66)
- # graalvm (3)
- # graphql (16)
- # jackdaw (1)
- # malli (1)
- # off-topic (11)
- # pedestal (4)
- # re-frame (10)
- # reitit (1)
- # rewrite-clj (8)
- # ring-swagger (8)
- # shadow-cljs (14)
- # spacemacs (2)
- # vim (5)
what's the best practice for "deleting" items and later being able to query them and restore them. In SQL you would record a deleted timestamp and use a WHERE deleted IS NULL in all queries... it seems in datomic one should just retract the entity?
but it seems the pulling deleted entities is somewhat cumbersome, you need to get the deletion tx instant and pull from db that is as-of one millisecond before the deletion
A 'deleted' marker like that seems different to a retraction, so why not use the marker? Would be more convenient. Also see two kinds of time here: https://vvvvalvalval.github.io/posts/2017-07-08-Datomic-this-is-not-the-history-youre-looking-for.html
But the down side is that every query would need to filter out deleted items in where clause
True enough. And you might want it to be an instant in 'event time' rather than a boolean. Also you could have another entity with all the same attributes and then the 'deleted' attribute as well. More work do do at the time of deletion (shuffling it into another entity), but then you wouldn't have to filter out for everyday queries.
That is true, and I've always disliked it... you can work around it in SQL by using views.
@tatut suggestion: create a new entity type like {:retraction/before tx, :retraction/eid eid}. When you retract your entity, invoke a transaction function that creates the "retraction" entity. Under :retraction/before, store the tx of the t of the in-transaction database. You can later use it to restore the db as-of the time of deletion. Under :retraction/eid store the entity ID of the retracted entity.
this would be out of the way of your usual queries and gives you the ability to find it again, reference the "retraction" in other context etc.
I'd only do it if I have to, because usually a history or log query does the job if I want to restore something deleted