This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (10)
- # beginners (18)
- # boot (29)
- # capetown (2)
- # cider (46)
- # cljs-dev (1)
- # cljsrn (69)
- # clojure (126)
- # clojure-android (9)
- # clojure-gamedev (3)
- # clojure-greece (16)
- # clojure-poland (13)
- # clojure-russia (45)
- # clojure-spec (27)
- # clojure-uk (21)
- # clojurescript (99)
- # cursive (1)
- # datascript (1)
- # datomic (42)
- # functionalprogramming (10)
- # hoplon (47)
- # instaparse (12)
- # jobs (5)
- # jobs-rus (9)
- # keechma (22)
- # lein-figwheel (8)
- # leiningen (5)
- # luminus (1)
- # mount (7)
- # off-topic (1)
- # om (15)
- # onyx (47)
- # other-languages (14)
- # planck (28)
- # proton (8)
- # re-frame (30)
- # reagent (15)
- # remote-jobs (3)
- # slack-help (2)
- # untangled (9)
- # yada (6)
[277076930200636 102 #uuid "577ae77c-6c62-407f-8123-d48f40dc399f" 13194139534395 true]
When using lookup refs in
d/q, an invalid input will raise an exception like
java.lang.IllegalArgumentException: Cannot resolve key: [:cat.feature/slug "asdf"]
If I want to handle these gracefully (say, return a 404 instead of 500), what's the best way to do that?
1. catch IllegalArgumentException
2. check if the lookup ref check out before (using
(->> lookup-ref (d/entity db) :well.known/attr) perhaps)?
i'd go with 2., @pesterhazy; presumably your LRs are user input coming in off the web. you'll want to validate those, just like any other user input
@pesterhazy: I'd probably use
d/entid instead of
(d/entid (rdb) 12341234) returns 12341234
so it won't discover if an entity-id does not exist
I know I shouldn't be using entity ids anyway, so I guess the real solution would be to stop doing that
Hey all, I’m storing a multigraph in datomic, and I’m interested in the shortest path (or all paths) between 2 or more vertices. I found one example https://hashrocket.com/blog/posts/using-datomic-as-a-graph-database Here, using rules, the author @jgdavey (thanks for the post) was able to get back a path, provided he specified the depth to search. Since that approach is very limited he ended up just working with pure datoms to do the graph search stuff I found a number of papers about implementing recursive algorithms in datalog http://blogs.evergreen.edu/sosw/files/2014/04/Green-Vol5-DBS-017.pdf http://web.cs.ucla.edu/~zaniolo/papers/tplp01.pdf but before trying to convert those into the datomic flavored datalog syntax I know and love, I wanted to see if anyone else has an opinion on this. Has anyone used Loom and Datomic together? Are there some smart patterns for using rules to do recursive querying? Or is @jgdavey’s approach still the best 2 years later?
@conaw I ended up using the raw
datoms access in part because there was so much less overhead than using the datalog approach. I’d love to see what implementations of those whitepapers would look like (selfishly), but my hunch is that the raw
datoms approach is nearly always going to be more performant.
OK, so if I `(d/transact conn [[:db.fn/retractEntity :foo]], and on the next line (d/entity (d/db conn) :foo), it’s not nil. What am I missing?
I think entity always returns a ‘map' with the id you give it even if it does not exist … I feel like I have to do a query to test for existence
@eraserhd: @hueyp is correct. Entities exist independent of whether they have any currently asserted values.
From the Entity documentation: Entities do not "exist" in any particular place; they are merely an associative view of all the datoms about some E at a point in time. If there are no facts currently available about an entity, Database.entity will return an empty entity, having only a :db/id. (http://docs.datomic.com/entities.html)
Did you get a new database value between issuing the retraction and doing the query?
transact blocks regardless of deref. i think it just returns a promise to conform with
Yeah, it failed because one of the entities being retracted was an attribute definition.