datomic 2024-05-21 | Slack Archive

wevrem00:05:16

How can I query for an attribute where the value has been retracted? Is that what the built-in missing? function is for? But I don’t think I can use that inside an or clause.

wevrem00:05:03

I want to be able to pull entities that have had a new value asserted, or the last value retracted, after a certain point in time, after a specified t-basis. Just exploring I did this:

(d/q '[:find ?tt ?op
       :in $
       :where [?tt :my-attribute _ _ ?op]]
     db)

But it only returns tuples with ?op equal to true. But I was hoping to get some false’s in there, in cases where I know I’ve retracted :my-attribute.

wevrem00:05:49

And I don’t think missing? is really what I want, because there are lots of entities that are missing this attribute. I specifically want entities where the attribute has been retracted: it used to exist, but now, or since a certain point in time, it doesn’t.

Joe Lane00:05:59

You cannot retract attributes

wevrem01:05:09

I guess I mean values that have been retracted. I’ve edited the original.

wevrem01:05:20

I’m reading now about d/history…👀

Joe Lane01:05:51

Enjoy!

Joe Lane01:05:07

https://docs.datomic.com/resources/day-of-datomic.html

wevrem01:05:30

I have watched those videos before, but there is no way I can remember everything covered. Or know where in a particular video some tidbit might be mentioned. But searching for “retract” on the datomic docs site led me to history and that seems to be the ticket. I can combine a d/since with a d/history and it gives me all retractions and assertions since a particular point in time, which is exactly what I needed.

👍 1

Joe Lane01:05:15

Glad you found what you were looking for! I wasn't suggesting to watch all 5 hours, sorry about that. I was just searching for the history section of the github repo

Dimitar Uzunov09:05:32

In the datomic docs the following is mentioned about DynamoDB, does the same principle apply for i.e. AuroraDB, Azure SQL and other SQL databases?

As a first rule of thumb, you should spend at least as much money on read+write capacity as you do on the transactor instance

jaret14:05:42

No, that only applies to provisioned storages and is under the DDB heading where we need to provide guidance on capacity settings.

Dimitar Uzunov14:05:05

thanks @U1QJACBUM! Is there an equivalent rule of thumb for SQL storages?

jaret15:05:34

I don't think so as DDB is unique in allowing you to independently specify read and write capacity. Perhaps there are SQL offerings out there that allow you to do this and any such offering I would start by applying said rule ^ The most common rub I see in SQL storage users (entirely unrelated to to read and write) is operational issues like not running datomic level gc and storage level maintenance (i.e. postgres vacuum) leading to a higer than expected cost of disk increasing. If your disk storage costs are high thats the first place I look.

👍 1

Maciej Szajna11:05:32

Hi guys! I'm trying to use input vars to add dynamic behaviour to otherwise static queries. The idea is to attempt to unify an input with a ground value, and if that succeeds the query goes on, otherwise it breaks there. Here's the basic idea:

(d/q '[:find ?result
       :in $ ?should-proceed?
       :where
       [(ground true) ?should-proceed?]
       [(ground "result") ?result]]
     db true) ;;=> #{["result"]}

Edit: not finished yet, sorry! The problem is, if I set the input to false, I still get the result!

(d/q '[:find ?result
       :in $ ?should-proceed?
       :where
       [(ground true) ?should-proceed?]
       [(ground "result") ?result]]
     db false) ;;=> #{["result"]}

If you, like I wonder, "what's the value of ?should-proceed?", well:

(d/q '[:find ?result ?should-proceed?
       :in $ ?should-proceed?
       :where
       [(ground true) ?should-proceed?]
       [(ground "result") ?result]]
     db false) ;;=> #{}

it's quantum, only collapses when looking at. Is this a bug?

jaret12:05:34

@U9RRPR0KE What version of Datomic are you using?

Maciej Szajna12:05:26

com.datomic/peer {:mvn/version "1.0.7021"}

Keith19:05:18

What's the :sched that's returned if you request https://docs.datomic.com/reference/query-stats.html#phases?

Maciej Szajna19:05:50

This is the first time I hear about :query-stats, very interesting. This is what I get:

Maciej Szajna19:05:54

(([(ground $__in__2) ?should-proceed?] [(ground true) ?should-proceed?] [(ground "result") ?result]))

Keith19:05:24

If you also look at :clauses and compare each of the queries you posted, do you see any difference that might explain the return values you're seeing?

Maciej Szajna19:05:21

[{:clause [(ground $__in__2) ?should-proceed?], :rows-in 0, :rows-out 1, :binds-in (), :binds-out [?should-proceed?], :expansion 1} {:clause [(ground true) ?should-proceed?], :rows-in 1, :rows-out 0, :binds-in [?should-proceed?], :binds-out []} {:clause [(ground "result") ?result], :rows-in 0, :rows-out 1, :binds-in [], :binds-out [?result], :expansion 1}]

Maciej Szajna19:05:40

not sure what rows-in/out is really about, but it appears the engine does understand should-proceed? is a 'bind-in" in this context

Keith20:05:22

Correct, but if you compare that to the query where you included ?should-proceed? in your :find clause, you should see that :binds-in in the last clause contains ?should-proceed? which is ultimately what causes the query to return an empty result.

2024-05-21

Channels