This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-09-01
Channels
- # admin-announcements (11)
- # announcements (1)
- # beginners (1)
- # boot (36)
- # cider (8)
- # cljs-dev (13)
- # clojure (65)
- # clojure-berlin (18)
- # clojure-russia (54)
- # clojurescript (137)
- # code-reviews (3)
- # datomic (30)
- # emacs (9)
- # events (13)
- # hoplon (36)
- # jobs (1)
- # ldnclj (4)
- # melbourne (15)
- # off-topic (2)
- # om (4)
- # re-frame (5)
- # reagent (25)
- # sydney (3)
- # testing (1)
probably better to test the lookup in isolation first
@robert-stuttaford: but then if you want transactionality, you've gotta be in a db function 😕
So it's better to do a query before a transaction, to first ensure that a Lookup Ref exists?
@sdegutis: taking a step back — how do you want to handle the failing case? If you want to create if it doesn’t exist, but update if it does, then you may just want to use unique/identity and provide the unique att/val on an entity w/tempid to get upsert behavior as described here: http://docs.datomic.com/identity.html#unique-identities
@bkamphaus: In this case I just want to return :invalid-user
from this function if the user doesn't exist.
@sdegutis If you’re not expecting much nuance around coordination I would probably just do the existence check with query as @robert-stuttaford mentioned, rather than waiting for the exception to get thrown by the transaction attempt.
Just want to ping any Datomic team members here about a bug I've reported before: Queries that use both pull and the scalar find spec (`[:find (pull ?e [*]) . …]`) that are done via the rest api return results that are in a different shape than you'd expect. If, in a repl, you get {:a 1 :b 2}
as a result, the same query will return [[:a 1] [:b 2]]
via the rest api.
yay! we'll have more details on that in the next few weeks, lots of cool stuff in the works for it.
Also it would be cool if you could do a recursive Lookup Ref, like [:account/user [:user/email "
@sdegutis: hah I have just come to accept the way the clauses look stacked beneath :where but yes that does bug me when I think about it
@shaunxcode: I've often used the map-literal style instead of the vector-literal style, but that gets verbose.
But it's the only way I can get the indentation right if I have more than one :where
-clause.
Question: does it make sense to use a pull-expression inside a (d/q ...)
query, or is that literally equivalent to just putting another :where
clause in there?
FWIW, this is I get with default formatting in vim, and it's been fine for a couple of years worth of a project:
(d/q '[:find ?foo
:in $ ?thing
:where
[?id :foobar/baz ?thing]
[?id :foobar/foo ?foo]]
db
thing)
@kbaribeau: When it comes up is if you put the first where-clause on the same line as the :where word.
maybe in a really short query, but for multiple where clauses it looks so much neater with where on its own line
re: pull, stacking where clauses is pretty verbose. before they added pull I used the entity API a lot because of that
(d/q '[:find ?foo ?bar ?wha
:in $ ?thing
:where
[?id :foobar/baz ?thing]
[?id :foobar/bar ?bar]
[?id :foobar/wha ?wha]
[?id :foobar/foo ?foo]]
db
thing)
;--------- VS ------------
(d/q '[:find (pull ?id [:foobar/foo :foobar/bar :foobar/wha])
:in $ ?thing
:where
[?id :foobar/baz ?thing]]
db
thing)
(plus or minus a syntax error maybe, I didn't try to execute that)@kbaribeau: Ah good point.