@devth they can't, and you can definitely benefit from the client itself having some notion of a tempid. Note than you can also use unique-identity attribute for upsert, e.g {:a/id "some-id" :a/b {:b/id "some other id"}} instead of {:a/id "some-id" :a/b [:b/id "some other id"]}

Be careful of the security issues that can be caused by sending that from the client though

How would one query Datomic for any entities where attr1 has value a OR attr2 has value b? I can't use an or clause because the attrs are different. I feel like I might be missing something simple here.

Not sure if this is the best solution, but you could always do two queries and combine the results afterwards.

@jeff.terrell Yeah. That's my fallback option. I'm just surprised that there is (apparently) no way to do this in one query.

@cap10morgan are you absolutely sure or clause is not what you need? i do use it with different attrs….. ??

it seems to me like it is is EXACTLY for that reason. on one attr you can have logical or by binding a collection

@karol.adamiec I got an error when I tried and the docs say: "All clauses used in an or clause must use the same set of variables, which will unify with the surrounding query. This includes both the arguments to nested expression clauses as well as any bindings made by nested function expressions."

ahh, yes

so the issue is in binding ;/

but maybe I'm doing it wrong 🙂

so OR claus works for :attr1 :attr2 only when it is bound to the same variable a

seems like two queries then 😞

@cap10morgan show us the clauses. You probably need or-join

the key is "same set of variables" (for unification), NOT same attributes

ah, so maybe (or-join [?user] ...?

hey, that seems to work. thanks @favila!

oh, huh. it looks like the or-join version does not work. it finds every user b/c the ?email-search and ?phone vars don't get unified with their inputs I guess?

so the relation binding version might be the way to go

(d/q '{:find  [[(pull ?user [*]) ...]]
       :in    [$ ?email-search ?phone]
       :where [(or-join [?user ?email-search ?phone]
                 [?user :user/email-search ?email-search]
                 [?user :user/phone ?phone])]}
  (d/db c) "" "+14055556666")

@cap10morgan ^

huh, I would have thought that was what it was doing w/o or-join

interesting

thanks again @favila

or adds the additional restriction of all clauses using the same vars

I'm not sure if that's just for safety or for an optimization

Now I'm wondering which one I prefer. Do you prefer the or-join over the relation binding, @favila?

explicit or-join is the only thing you can do if you have to check more than one pattern to match a condition

e.g., if you grow a "contact" entity and move all phone and email into those

or-join is probably also faster, since the query compiler can see what attrs it needs to look up

(although I don't know if it's fast enough to make a difference)

I would only use the relation biding form if I needed its generality

i.e., I had a set of different attributes I could match on, all attrs are on the same entity, and my searches could have one or many in any combination

yeah, makes sense. thanks!

so, my decision for one or the other is driven by interface more than anything

What (performance) concerns should I have when using ground?

how are you using it?

Two uses: - {:find [?name-e ?e] :where [[(ground (quote ?e)) ?name-e] ...(stuff)...]} - To know the "name" of each match - {:find [?e] :where [[(ground 12313) ?e] ...]} - To force the match to occur in a specific entit(ies) In general, these 2 uses at the same time. Queryies, with ground at begin of where, are taking ~100ms on an "empty"(very small background), mem, db.

how does that first one work?

ground is supposed to take literals, so the value of ?name-e is either (quote ?e) (a list) or ?e (a symbol)

I am interested in how you use it in (stuff) because I can't think how that would work

the second case you could make ?e input to the query?

but that is a legit use and I don't think any other way of getting ?e and its value at the same time would be faster

(d/q '[:find ?xv . :where [(ground (quote ?x)) ?xv]]) ;=> ?x @souenzzo

{:find  [?e688269 ?e
          ?stage1688270 ?stage1
          ?stage2688271 ?stage2
          ?date-close688272 ?date-close
          ?date-open688273 ?date-open]
  :where [[(ground 17592186046417) ?stage2]
          [(ground #inst"2017-11-29T20:44:21.770-00:00") ?date-close] ;;**
          [(ground (quote ?e)) ?e688269]
          [(ground (quote ?stage1)) ?stage1688270]
          [(ground (quote ?stage2)) ?stage2688271]
          [(ground (quote ?date-close)) ?date-close688272]
          [(ground (quote ?date-open)) ?date-open688273]
          [?e :stage-container/calendar ?stage1]
          [?e :stage-container/calendar ?stage2]
          [?stage1 :calendar/stage-type :stage-type/a]
          [?stage2 :calendar/stage-type :stage-type/b]
          [?stage1 :calendar/close ?date-close]
          [?stage2 :calendar/open ?date-open]]}

On ;;**, it's auto generated basead on other query. I dont know what results are entities-id, what are values...

well, it seems a little weird, but it does what you intend

I’m trying to write a query that checks whether a condition is sufficient for the last 4 out of 7 days. any suggestions on how to structure the datalog?

I have a workaround.. I can just run my condition query 7 times. but I’d appreciate any suggestions for a more efficient solution!