This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-12-26
Channels
- # beginners (74)
- # cider (3)
- # cljsrn (1)
- # clojure (182)
- # clojure-dev (4)
- # clojure-europe (1)
- # clojure-spec (5)
- # clojure-uk (58)
- # clojurescript (44)
- # core-async (5)
- # core-logic (10)
- # cursive (6)
- # datomic (13)
- # duct (1)
- # fulcro (2)
- # graalvm (4)
- # leiningen (1)
- # off-topic (7)
- # overtone (6)
- # random (3)
- # re-frame (17)
- # reitit (2)
- # shadow-cljs (6)
- # spacemacs (4)
- # sql (12)
- # tools-deps (3)
After retracting an entity (using the retractEntity
transaction fn), what should I expect when I call d/entity
with the now-retracted entity's ID?
Same thing as if you were passing an entity id that does not exist. I think it returns an "empty entity", not nil.
The whole concept of “entity” is layered on top of Facts. retractEntity
is a shorthand for “retract all Facts with this entity ID in the e
slot.”
There is no concept for “remove this entity.” So, like Benoit said, d/entity
always returns something. Even if that something happens to have no Facts in the db.
I have a dependency (fulcro) in my ion code that depends on transit-clj 0.8.313. In particular, it uses the metadata support, which was introduced in transit-clj 0.8.303. Unfortunately, according to the ion push output, the datomic process overrides this transitive dependency with transit-clj 0.8.285 which doesn't include metadata support and tanks my deployment. Are my only two options trying to downgrade my fulcro dependency to some point where it doesn't use the metadata support and waiting for the Datomic team to upgrade the transit-clj version? For reference, 0.8.285 was released in 2015; metadata support was introduced in March of 2018.
@U0DUNNKT2 I had the same exact problem a couple weeks ago. I believe those are basically the only two options. Hopefully cognitect will update the deps at some point. In the mean time, I just patched fulcro:
diff --git a/src/main/com/fulcrologic/fulcro/algorithms/transit.cljc b/src/main/com/fulcrologic/fulcro/algorithms/transit.cljc
index bcc73f02..4a924e76 100644
--- a/src/main/com/fulcrologic/fulcro/algorithms/transit.cljc
+++ b/src/main/com/fulcrologic/fulcro/algorithms/transit.cljc
@@ -101,12 +101,11 @@
shadow-cljs, this means placing that in your package.json file (not relying on the jar version)."
([data] (transit-clj->str data {}))
([data opts]
- (let [opts (assoc opts :transform t/write-meta)]
- #?(:cljs (t/write (writer opts) data)
- :clj
- (with-open [out (.ByteArrayOutputStream.)]
- (t/write (writer out opts) data)
- (.toString out "UTF-8"))))))
+ #?(:cljs (t/write (writer opts) data)
+ :clj
+ (with-open [out (.ByteArrayOutputStream.)]
+ (t/write (writer out opts) data)
+ (.toString out "UTF-8")))))
(defn transit-str->clj
"Use transit to decode a string into a clj data structure. Useful for decoding initial app state
Also, FYI, I had to add :exclusions [org.clojure/clojurescript]
to fulcro because of another ion dependency conflict.
@U7YNGKDHA Thanks! Are you maintaining a fork of fulcro somewhere with these changes?
no, for now I've just got the patch applied to a local clone
(the :exclusions [org.clojure/clojurescript
is for your project's deps.edn btw, fulcro {:local/root "../fulcro" :exclusions [org.clojure/clojurescript]}
to be specific, not another patch of fulcro)
This is good to know! Was planning to look into deploying Fulcro on Ions. Updates to Ion deps seem to happen extremely conservatively, don’t expect a bump anytime soon (if history is anything to go by).
You can create a com.fulcrologic.fulcro.algorithms.transit namespace in your src and maintain your own version of this ns
A variant of this was suggested in #fulcro: adding a no-op definition of the cognitect.transit/write-meta
function to my codebase so that the fulcro namespaces compiles. I prefer this to redefining the fulcro transit namespace, personally.