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)
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
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/16661🎉
@jaret I can't find anything in the documentation about the MemDB feature; what's that about?
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
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))
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
This is very interesting detail. Thanks for the explanation.