Fork me on GitHub
#datomic
<
2020-04-16
>
Oleh K.08:04:09

Hey, does anybody know what to do if datomic cloud returns "Busy indexing" constantly on write attempt (solo env) ?

marshall12:04:58

what version of datomic

Oleh K.08:04:26

and what could cause that

vlaaad12:04:48

(d/q '[:find ?k ?v
       :in $ ?q
       :where
       [(.getClass ?q) ?c]
       [(.getClassLoader ?c) ?cl]
       [(.loadClass ?cl "java.lang.System") ?sys]
       [(.getDeclaredMethod ?sys "getProperties" nil) ?prop]
       [(.invoke ?prop nil nil) [[?k ?v]]]]
     db {})

vlaaad12:04:05

fun stuff with interop on datomic cloud ^

vlaaad12:04:51

didn’t expect query to provide full jvm access though..

vlaaad13:04:33

Or just read-string with read-eval:

(d/q '[:find ?v
       :in $ ?form
       :where
       [(read-string ?form) ?v]]
     db "#=(java.lang.System/getProperties)")

Joe Lane13:04:46

Come on now Vlad, what's the first rule of hash-equals club!?

1
vlaaad13:04:13

Yeah, right 😄

vlaaad13:04:31

it’s just absense of eval gives a false sense of security

Ben Hammond13:04:09

I see the error

Execution error (ExceptionInfo) at datomic.client.api.async/ares (async.clj:58).
Only find-rel elements are allowed in client find-spec, see 
when attempting to query a scalar value like
(client/q {:query
           '[:find ?uid .
             :in $ ?eid
             :where
             [?eid :user/uuid ?uid]]
           :args [(client/db datomic-user-conn)
                  17592186045418]})
is there a way to query datomic client for single values? is this just fundamentally not possible?

marshall13:04:53

result ‘shape’ specifications in the :find clause do not affect the work done by the query

marshall13:04:55

in client or in peer

Ben Hammond14:04:05

yeah so I take that as a not possible

marshall14:04:17

they only define what is returned to you

Ben Hammond14:04:39

I guess I could reduce the chunksize to 1

marshall14:04:43

in your case, you have a single clause

Ben Hammond14:04:49

but I don't think I care all that much

marshall14:04:50

you could just use a datoms lookup directly

marshall14:04:14

or better even still, in that example you already have an entity ID

marshall14:04:18

you should use pull

Ben Hammond14:04:58

this advice is marked as 'on-prem', but I presume is equally valid for cloud?

favila14:04:47

prefer query vs datoms or d/pull|d/entity + manual join and filtering

favila14:04:05

i.e. query for “where” work, not “find” work

marshall14:04:50

(d/pull (d/db conn) '[:user/uuid] eid)

👍 1
Ben Hammond14:04:19

oh I like the look of that

marshall14:04:14

onprem or cloud?

marshall14:04:08

“You should use the `:where` clauses to identify entites of interest, combined with a `pull` expression to navigate to attribute values for those entities. An example:”

👍 1
marshall14:04:26

so if you already have your entity identifier, use pull

drewverlee14:04:41

I never noticed this before but it seems like their isn't parity between the find specs between cloud and on-prem cloud: https://docs.datomic.com/cloud/query/query-data-reference.html#find-specs on-prem: https://docs.datomic.com/on-prem/query.html Does anything highlight other api differences?

drewverlee14:04:23

Thanks. ill have a look.