Fork me on GitHub
#datomic
<
2015-09-01
>
robert-stuttaford07:09:12

probably better to test the lookup in isolation first

tcrayford09:09:16

@robert-stuttaford: but then if you want transactionality, you've gotta be in a db function 😕

sdegutis14:09:08

So it's better to do a query before a transaction, to first ensure that a Lookup Ref exists?

bkamphaus15:09:00

@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

sdegutis18:09:23

@bkamphaus: In this case I just want to return :invalid-user from this function if the user doesn't exist.

bkamphaus18:09:25

@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.

sdegutis19:09:57

Cool thanks simple_smile

bhagany19:09:07

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.

bhagany19:09:48

Also, just signed up for the Datomic training at the Conj, so, yay simple_smile

alexmiller19:09:14

yay! we'll have more details on that in the next few weeks, lots of cool stuff in the works for it.

sdegutis19:09:21

Also it would be cool if you could do a recursive Lookup Ref, like [:account/user [:user/email ""]]

sdegutis19:09:36

Right now it needs a query, but it would be cool if it could.

sdegutis20:09:32

Anyone got a solution for correctly indenting multiple :where clauses in Emacs?

shaunxcode21:09:03

@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

sdegutis22:09:39

@shaunxcode: I've often used the map-literal style instead of the vector-literal style, but that gets verbose.

sdegutis22:09:07

e.g. [:find ?foo :where [?foo :foo/bar]] == {:find [?foo] :where [[?foo :foo/bar]]}

sdegutis22:09:29

But it's the only way I can get the indentation right if I have more than one :where-clause.

sdegutis22:09:04

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?

kbaribeau22:09:13

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)

sdegutis22:09:04

@kbaribeau: When it comes up is if you put the first where-clause on the same line as the :where word.

kbaribeau22:09:13

yeah, I just never do that

sdegutis22:09:25

ok cool me too

kbaribeau22:09:48

maybe in a really short query, but for multiple where clauses it looks so much neater with where on its own line

kbaribeau22:09:45

re: pull, stacking where clauses is pretty verbose. before they added pull I used the entity API a lot because of that

kbaribeau22:09:26

(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)

sdegutis23:09:48

@kbaribeau: Ah good point.