idk about simplest, but we’ve used cloudwatch cron events to trigger an ion lambda

Ah, did not know cloudwatch had that. And, of course, would prefer something not-in-AWS.

datomic cloud is always in aws

it is easier to control the cron job than to build some threads that are run on all nodes of the compute group, but ymmv

I am definitely not syncing threads across all nodes, that seems like an invitation to screw up! I’ll give in to cloudwatch and triggering ions, thank you

nm, didn’t read carefully

This way seems to be working

[:find ?e
 :in $ ?email ?phone ?id
 :where
 (or-join [?e ?email ?phone]
          [?e :worker/email ?email]
          [?e :worker/phone ?phone])
 (not [?e :worker/id ?id])]

As much as I tested it

yes that is correct.

The reason was cause of input parameters but not values?

All “branches/implemenations” of a rule must have the same bindings. If you don’t specify bindings the parser infers them from whatever bindings it sees in each branch. If they don’t match, you get that warning

If I set values in place of input arguments it works with or also

or-join (and all -join variants) say explicitly what bindings there are. implementations that don’t use a binding will just not unify against it, which is what you want here

you want one implementation to unify against email and ignore phone, and the other to do the opposite

and the results from both are set-unioned

Thanks, seems that I meeting this case regulary and forget the rules every time after )

It helps me to think of or* and and* as just syntax sugar for rules, and think about the rule I would write

Thanks again, I'l try to rethink my mental model of it

e.g. this would be [[(worker-phone-or-email ?e ?phone ?email) [?e :worker/email ?email]]…] Saying (worker-phone-or-email ?e ?phone) for one impl and (worker-phone-or-email ?e ?email) for the other would be more obviously wrong

maybe I'l just rewrite query to use direct values instead of input parameters, cause I still dont understand this -join magic perfectly

Working with Clojure is much understandable than with datomic )