Clojurians Log v2

are subqueries only possible with ions? i'm fooling around and i'm running into cognitect/not-found errors that tell me "'datomic/ion-config.edn' is not on the classpath"

here's the subquery i attempted:

(d/q `[:find ~'?contract ~'?latest-snapshot-tx-instant
         :where
         [~'?contract :contract/id]
         [(datomic.client.api/q [:find (~'max ~'?snapshot-tx-instant)
                                 :where
                                 [~'?contract :contract/snapshots ~'?_ ~'?snapshot-tx]
                                 [~'?snapshot-tx :db/txInstant ~'?snapshot-tx-instant]])
          ~'?latest-snapshot-tx-instant]]
       db)

use [(q @michael740

that gets me further... thank you!

a humble suggestion to whoever may have control over the documentation: i could not find the q function documentation when googling "datomic subquery"

Q: I want to use an API-Gateway custom authorizer (lambda) with Ions. The authorizer decorates the request which is passed through to the Ion Lambda (I’m not using http-direct yet). The auth data is in the lambda request “context”, not in headers. Using a ring handler which has been “ionized” I can’t figure out how to access that data. Has anyone got any experience with this?

I found the answer in the docs. the “requestContext” is in the web ion request

https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format

Cognitect dev-tools version 0.9.51 now available Version 0.9.51 of Cognitect dev-tools is now available for download. See https://forum.datomic.com/t/cognitect-dev-tools-version-0-9-51-now-available/1666

@jaret I can't find anything in the documentation about the MemDB feature; what's that about?

@vincenz.chianese Sorry the doc's cache wasn't busted

https://docs.datomic.com/cloud/dev-local.html#memdb

Ah ok sweet, thanks!

What's the idiomatic way to > retract (`:db.fn/retractEntity`) all the releases that have a particular given :release/artist, and return the list of :release/name's of the releases retracted, all done atomically I know that the first part can be done with a transaction function, and the second part can be extracted manually from the "TX_DATA" key in the transaction report map. However, I found manual extraction to be too much dependent on the structure of the transaction report map, which seems to be rather subject to future changes. I was wondering if there's a more elegant way of doing this that I am not aware of.

the tx-data report map has been stable for years AFAIK. what difficulty are you encountering specificaly?

My go-to strategy in this case would be to look in tx-data for datoms matching pattern [_ :release/name ?value _ false] . That will only tell you that a value was retracted, not that a retractEntity caused it. With some domain knowledge you could refine that further

(note you’ll have to resolve :release/name to its entity id somehow)

> look in tx-data for datoms matching pattern ... Interesting ... does Datomic provide a mechanism to do this kind of matching against a list of datoms? @favila

@favila Or do I have to do (map #(nth 2 %) (filter (fn [[e a v t f]] (and (= :release/name a) (not f))) (:tx-data query-report)))?

That should be enough; if you need more sophistication you can use d/q with the :db-before or :db-after dbs

e.g., I want all release names for all entities which lose a release name but don’t gain a new one within a transaction (i.e. they only lose, not change their name):

(d/q '[:find ?release-name
       :in $before $txdata
       :where
       [$before ?release-name-attr :db/ident :release/name]
       [$txdata ?e ?release-name-attr ?release-name _ false]
       ($txdata not [?e ?release-name-attr _ _ true])
       ]
     (:db-before result) (:tx-data result))

(untested)

I think this is what I was looking for. Thanks!

@favila Wait ... wasn't [$before ?release-name-attr :db/ident :release/name] implied? Why did you have to put it in the query?

$txdata is a vector of datoms, which is a valid data source, but doesn’t understand that :release/name is an ident with an equivalent entity id. So just putting [$txdata _ :release/name] would never match anything

that you can say [_ :attr] or [_ :attr [:lookup "value"] or [_ :attr :ident-value] is magic provided by the datasource

the database “knows” that those map to entity ids and does it for you

but a vector datasource isn’t that smart

so you need to match the entity id of :release/name exactly

This is very interesting detail. Thanks for the explanation.