is it possible to query against an as-of db within a datalog query; something like

(d/q '[:find ?e ?attr-name ?v ?tx ?user-id ?product-initial ?ingested-at
       :in $ [[?e ?a ?v ?tx]]
       :where
       [?e :user/id ?user-id]
       [(d/asof $ ?tx) ?e :historical/product-initials ?product-initial]
       [?tx :db/txInstant ?ingested-at]
       [?a :db/ident ?attr-name]]
     datomic-db
    previously-found-datom)

do I have to pass the historical db as a parameter to the datalog?

like

(d/q '[:find ?e ?attr-name ?v ?tx ?user-id ?product-initial ?ingested-at
       :in $current $historic [[?e ?a ?v ?tx]]
       :where
       [$current ?e :user/id ?user-id]
       [$historic ?e :historical/product-initials ?product-initial]
       [$current ?tx :db/txInstant ?ingested-at]
       [$current ?a :db/ident ?attr-name]]
     datomic-db
     (d/as-of datomic-db (:tx previously-found-datom))
     previously-found-datom)

Q: I’m getting ready to add a circuit breaker into my Ions for http calls. I’m considering https://github.com/sunng87/diehard and https://github.com/Netflix/Hystrix/tree/master/hystrix-contrib/hystrix-clj. Anyone got any experience with this pattern in Ions yet?

hystrix is somewhat deprecated I think fyi

Hystrix team seems to recommend https://github.com/resilience4j/resilience4j going forward.

does anyone know why the following would only seem to return the first 3-tuple rather than all of them across time (when run against (d/history db):

(def price-history-for-underlying
  '[:find ?price ?time ?tx
    :in $ ?sym
    :where
    [?und :underlying/symbol ?sym ?tx]
    [?und :underlying/price ?price ?tx]
    [?q :quote/underlying ?und ?tx]
    [?q :quote/time ?time ?tx]])

[not only are these inserted in the same call to transact but the underlying entity is actually nested under the quote entity via it's underlying attribute (both maps)].

:find returns a set

[the one wrinkle is that there are many quotes with the same underlying value all transacted at once. but that should be fine as long as everything inside the collection of maps passed to transact receives the same tx-id]

if [?price ?time ?tx] is the same across all you will get only one item

yes, i'm getting a set of one 3-tuple rather than a set of many 3-tuples

if you include ?sym or ?q does it change?

let me try

you're also joining all ?tx which seems odd

unless you actually do transact all at once

i do actually transact all at once

what i want is for tx to be fixed to various points in time

ok, adding ?sym did not get many but adding ?q did

you want tx-time = time-of-record?

or domain-time?

doesn't matter. tx-id or time both should be identical across all of these

:quote/time = tx time?

:quote/time is roughly wall clock time at the point of the insertion

why not == tx time?

because they're not equal 🙂

that's the red flag to me. generally it's really really hard to make tx time anything but a git-commit like audit history

you can set :db/txInstant

as long as you don't set it before the most recent one

time is just a piece of data. doesn't matter if it is skewed by a few hundred milliseconds. it is the time that the server quoted the price to me

so, txInstant will be several hundred milliseconds later

i am more interested in knowing that the price in question was the price at the moment that the server reported it for

hence its inclusion in the query

ok

so winding back, unless you include ?q you are not guaranteed a result per ?q

you can use :with to include a binding for the purposes of computing the result set but do not want to include it in the result set

https://docs.datomic.com/on-prem/query.html#with

hmm, ok. with may be the answer here. including q only got me the fan-out at a particular moment in time. i am still not getting the fan-out across all moments in time

:with ?q would ensure you got at least one result per q

i am more interested in getting at least one result per tx

and including ?tx in the :find doesn't seem to be doing that

and you are sure there is a unique ?q and ?und per ?tx

pretty sure. if that isn't true then much bigger problems are here. how can i verify it?

just remove the tx

from query and find

see what you get

(include the q)

or you can do a clause at a time

[:find ?q ?und ?tx :where [?q :quote/underlying ?und ?tx]

but if i'm not including the ?tx, how can i know how many ?tx's are accounted for in the result?

removing the tx is to be sure you actually have multiple entities

ah, right. sorry, lol

well this query is taking a long time

so, it is likely gonna return a lot of data

i have to leave now. i'll play more with this later. thx!

so, i got OutOfMemoryError on that query so i think it's safe to say that there are multiple entities

Hi, I'm sure you've got the question a thousand time before

but I am trying my hands with datomic

was trying to setup the dev storage

I put my key in the properties files

launch a transactor with .\bin\transactor .\config\dev-transactor.properties

I get back a message System started datomic:, storing data in: data

Then I try to launch a peer-server like in the tutorial using in memory storage

Command is bin/run -m datomic.peer-server -h localhost -p 8998 -a myaccesskey,mysecret -d mydb,datomic:

And I get an error Exception in thread "main" java.lang.RuntimeException: Could not find mydb in catalog

So I guess I need to create a catalog called mydb but how I am supposed to do?

I'm sorry I am very confused by the Datomic Architecture right now

@favila why is this only returning one transaction id?

core=> 
(def price-history-for-underlying
  '[:find ?tx
    :with ?und
    :in $ ?sym
    :where
    [?und :underlying/symbol ?sym ?tx]
;   [?und :underlying/price ?price ?tx]
;   [?q :quote/underlying ?und ?tx]
;   [?q :quote/time ?time ?tx]
    ])
#'core/price-history-for-underlying
core=> 
core=> (d/q price-history-for-underlying (d/history (db)) "OEX")          
[[13194139534793]]
core=> 

[and i think this is the root of the other problems i'm having]

because there is only one ?und?

what does a transaction look like

there is only one ?und but across time there are many