Fork me on GitHub
#datomic
<
2018-05-15
>
James Vickers01:05:24

Is there a way to mark a var as final in the same way you can mark a Java variable as final, to prevent it from being re-bound to another value?

favila02:05:24

You mean a datalog var?

James Vickers02:05:36

Sorry I’m in the wrong channel! Ignore me

octahedrion09:05:42

how do I use :db-after in a query ? The documentation https://docs.datomic.com/cloud/transactions/transaction-processing.html#results says "Both :db-before and :db-after are database values that can be passed to the various query APIs", but :db-after returned from a transaction is an ArrayMap and I can't find a way to use that map to create a datomic.client.impl.shared.Db for use in (d/q)

joshkh10:05:35

an answer to @octo221’s question might help me solve the problem of keeping two datomic cloud clients in sync https://stackoverflow.com/questions/50347307/how-do-i-keep-two-datomic-cloud-clients-in-sync

octahedrion12:05:53

@octo221 @joshkh it looks as though you use (d/as-of db t) where t is (get-in transaction-result [:db-after :t])

souenzzo12:05:54

as-of dont get a "future" db, just a past db (as-of is a filter) https://docs.datomic.com/on-prem/filters.html#as-of-not-branch

joshkh12:05:11

hmm, agreed. using as-ofwith a future value still doesn't "catch up" the db to the future.

joshkh13:05:54

unfortunately it's a no go. if someone from the cognitech team finds this, any advice would be very much appreciated! i've been trying to work it out for a few days and running queries twice is a nasty hack.

marshall13:05:09

@joshkh client does not currently have the feature to ‘get the latest db available’; that would be a good suggestion for a feature request in our feature portal currently, passing a t value is the correct method to ensure multiple clients share a basis

joshkh13:05:57

thanks, @marshall. does passing a future t value to the client's d/as-of (as @octo221 suggested) update the database value? i ran a test and unless i'm mistaken it suggests not.

marshall13:05:24

a ‘future t’ ?

joshkh13:05:11

i'm still out of the datomic nomenclature loop! if repl 1 transacts and results with a :t 100, and repl 2 is still at :t 99 and uses (as-of (d/db conn) 100) as the db value in a query, should the transaction from repl 1 be found?

marshall13:05:36

i believe so yes

joshkh13:05:02

i just gave it a shot and came up blank but i'll try again now

joshkh13:05:44

REPL 1 (db-after t value is 770)

(d/transact @conn {:tx-data [{:person/first-name "Alice"}]})
=>
{:db-before {:database-id "...",
             :db-name "datomic-test",
             :t 769,
             :next-t 770,
             :history false,
             :type :datomic.client/db},
 :db-after {:database-id "...",
            :db-name "datomic-test",
            :t 770,
            :next-t 771,
            :history false,
            :type :datomic.client/db},
 :tx-data [#datom[13194139534082 50 #inst"2018-05-15T13:14:44.154-00:00" 13194139534082 true]
           #datom[70804150782265703 73 "Alice" 13194139534082 true]],
 :tempids {}}
REPL 2 with explicit t value at 770 (is currently at 669)
(d/q '[:find (pull ?person [*])
       :in $ ?person-name
       :where
       [?person :person/first-name ?person-name]]
     (d/as-of (d/db @conn) 770)
     "Alice")
=> []

joshkh13:05:56

... where as the act of executing that queries does update the t value in REPL 2, and re-running the query for a second time does return the transacted value.

marshall13:05:08

understood - looking into it

favila13:05:28

@marshall this is an issue where d/sync is needed

joshkh13:05:32

thanks, @marshall. very much appreciated. it's a hurdle for us as we're sharing a cloud db across two applications. thanks for looking into it - i'm sure i'm just missing something obvious.

octahedrion13:05:21

@joshkh @marshall @favila I can confirm: 2 repls, in one I transact a datum, then wait plenty of time (seconds), then in the second repl I query for the datum just transacted using d/db to get the latest db value, but the result is [], then I immediately try the same query again and this time I get the result

octahedrion13:05:32

(using Datomic Cloud)

octahedrion13:05:39

what's more, it's the use of d/q which refreshes the db connection (or something), not the use of d/db, since if I first use a previous db value (without calling d/db in my first d/q) then use d/q with d/db I get the same behaviour

joshkh13:05:26

yes, exactly.

joshkh14:05:26

repl 1 vs repl 2 was a contrived example but representative of the larger services that we've already built, and folding them into a monolithic application that shares a single client connection isn't really an option for us as we're scaling across containers. i'm open to any work-around that gets us past this show stopper, even if it's the phantom query method, but i'm hoping that's not the case unless it's bullet proof.

👍 4
marshall14:05:04

@joshkh we’re looking into the issue; in the interim, you can also create a new connection to “force” update

joshkh14:05:22

thanks a lot, @marshall. that wasn't meant to sound all gloom-and-doom. just highlighting the problems it's causing downstream.

marshall14:05:40

understood.

joshkh20:05:45

@marshall is there a trackable issue we can check on for an update? slack is great but discussions tend to evaporate upwards over time. 🙂

joshkh20:05:43

(we're also snapshot friendly and happy to test anything unofficial)

favila20:05:58

Is there any way to use rules "bi-directionally" with decent performance?

val_waeselynck07:05:06

@favila I had this problem, hence made a feature for that in datalog-rules: https://github.com/vvvvalvalval/datalog-rules#reversed-rules-generation-experimental . Granted, it's a bit of a hack, I wish that was part of Datomic's API

👍 4
favila12:05:10

Short of datomic actually doing some query optimization, I wish I could use the bracket syntax on arbitrary arguments

favila12:05:34

And have datomic use that info to select the right impl at runtime