each time there is a transaction, a new one replaces the existing one

It looks here like you have one ?und per ?sym

yes, correct. and many :quotes per ?und

why do you expect many tx if you have only one und per sym?

because many calls to transact for that und/sym pair are occuring

roughly one every 10 minutes

the database is also growing so that "history" is there somewhere

assertions which don't change the value that is there already do not add datoms

oh, gotcha. in this case, the price is the part that should be changing

if :my-attr is card-one, [:db/add 123 :my-attr "my-value"] will only add a datom the first time

hmm, so perhaps i need ?tx on the :price and the :time attrs to tie these together

why are you joining on tx?

because i want the data to be consistent per some point in time

i.e., the tx

tx is a synch point

your data is consistent by virtue of your DB value

if these were one entity rather than two, no need for join

but since it is split into two related entities, i need to fix them to the same point in time no ?

yes, this worked!

the answer was:

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

i am now getting all prices across all time

thanks!

[?und :underlying/price ?price ?tx]

I don't understand this

it ensures that the ?und and the ?q that we select are "paired" together/, married together if you will, at a single point in time, namely at ?tx point in time.

is $ a history db or an ordinary db?

history

this will included retractions too

:underlying/price is cardinality-one and you keep writing over it?

or is it cardinality-many?

yea, it's one

and yea keep writing over it

so, if your price doesn't change from one-tx to the next, then you won't join

that's ok

the TX of the price will be from the previous tx

i only care when prices actually change

ok

that's fine

so it will effectively just "skip" over those

it's conventional to mark history databases with $h since they usually change the nature of a query substantially

instead of just $

ah, thx

you should also probably include true to ensure you are only matching assertions

history dbs also include retractions

In this case set-wise results will make it all work out but it's easy to imagine getting surprised by duplicates with some query changes

hmm, what is a "retraction" in this context? like a deletion?

btw, $h isn't working for me. it says "did you forget to pass a database?"

but just $ works fine

you put $h in front of every caluse

[$h ?e ?a ?v]

retraction is a deletion yes

hmm, ok

you can use d/datoms to see the actual stuff these clauses are matching against

if you use a history db, you will notice some datoms that end with "false"

those are retractions

Cool, thx

Hi. What I have to do to "update" my item in Datomic database and not add another one?

@m_m_m Your transaction must include one of the attribute that identifies the entity you want to update. https://docs.datomic.com/on-prem/identity.html

Hi, I'm having trouble finding which dependency to add to my project.clj to complete the dev setup

notably requiring datomic.api like (require '[datomic.api :as d])

In the getting started the dependency is [com.datomic/client-pro "0.8.28"]

but it doesnt work when using (require '[datomic.api :as d]), any pointer please?

Also doing bin\maven-install then mvn install:install-file -DgroupId=com.datomic -DartifactId=datomic-pro -Dfile=datomic-pro-0.9.5786.jar -DpomFile=pom.xmlgenerate an error

my bad on windows you have to escape things, so the correct command is mvn install:install-file -DgroupId="com.datomic" -DartifactId="datomic-pro" -Dfile="datomic-pro-0.9.5786.jar" -DpomFile="pom.xml"

I'm on cloud: export DATOMIC_ENV_MAP="{:env :local}" (ion/get-env) => "{:env :local}" ... it does not get read as EDN. What am I missing?

Ah. repl: export DATOMIC_ENV_MAP={:env :local}

And not: repl: export DATOMIC_ENV_MAP="{:env :local}" ... Makefiles are weird.

does anyone know how to use a java.util.Date instance in a predicate expression clause: e.g.,

[(<= ?time $before)]

ah, i think i need .before

per: https://groups.google.com/forum/#!msg/datomic/X3I0Ozd4d0I/EkANn6HRn3UJ

Not actually a spec/datomic question, but closely related. Do you have any tricks to alleviate some pain of "broken sugar" for long namespaces of a

... Datomic ident style naming convention where :datomic.client.protocol/response enumerated values are like :datomic.client.protocol.response/body, which breaks the sugar

Namespaces are usually the solution to this. Clojure uses them. XML too. I have no idea if this notion of namespace will come to spec though.

But no I have no trick except to not do that for every single piece of data inside your system 🙂

not sure what do you mean, @me1740. like "ns declared in some header"?

Global names make the most sense for public interfaces.

Yes, I meant a mechanism to declare the namespace for a given context.

the problem is that key namespaces don’t compose with the normal keyword operations. you can’t derive :datomic.client.protocol.response.error/status directly from :datomic.client.protocol.response/error

yeah, but as soon as you have several origins for the "same" key-val, having short implicit ns for your app key, and long global ns for external key – is kinda e.g.: :myapp/email and :oauth2.gmail/email (assuming ofc gmail ns would be much longer :) )

yeah, this is probably what I'm fishing for, @lilactown. some approach to juggle these "hierarchical"-but-not-really keywords

which does not break various destructuring sites, go-to-spec-definition in IDEs, etc. along the way

yeah. you can probably come up with a clever helper function for your s/def’s, but it falls over when trying to destructure

speaking of destructuring: as soon as you have :foo/id and :bar/id in the same map – you often have to go w/o destructuring too :(

yeah. it’s really annoying how destructuring completely loses the keyword ns. merging maps is easy but tearing off data requires more work

which, I hate to admit, makes :foo-id and :bar-id more appealing.

I usually end up doing something like:

{foo-id :foo/id bar-id :bar/id} big-map

which often longer than just (:bar/id big-map) once later in the fn

well, I usually like tear off all my data in one place. but yes, it’s not exactly pushing us into the pit of success

and is "naming same things over and over again" which Rich hates so much in java signatures and pattern matching

which brings us back to forms explosion, when keyword's ns is long enough (take any from https://gist.github.com/dustingetz/e3d0650d903d95ffe1cab1b343cfa073 from same reddit thread): :datomic.client.protocol.response/error

from short and sweet hello world form to enterprise in 2 seconds

also clojurescript does not have the alias fn (?)