Are you passing the date as the first argument instead of the second?

Nope, here's my code

(let [time (tc/to-date
            (t/from-time-zone (t/date-time 2019 10 22 16 50 0)
                              (t/time-zone-for-offset +8)))
      db-then (d/as-of (d/db conn) time)]
  (d/q '[:find ?doc
         :where [_ :db/doc ?doc]]
       db-then))

and db-then is a db...

(let [time (tc/to-date
            (t/from-time-zone (t/date-time 2019 10 22 16 50 0)
                              (t/time-zone-for-offset +8)))
      db-then (d/as-of (d/db conn) time)]
  (type db-then)) => datomic.client.impl.shared.Db

Found via https://twitter.com/andy_pavlo/status/1186636813458432000

you need to permissions to access those s3 files

did you see that file in s3 ?

I'm new to AWS. I made an IAM user and gave him AmazonS3FullAccess permissions. Is that enough? How can I test access to those files?

I'm now the root user and still same problem. I'll try and delete and re-create the cloud-formation. maybe this helps

What does that gain over retractEntity?

Ah yeah, good point.

Just looking ahead to see if this is a known bad idea. I’m gathering that it’s probably just fine tho.

a minor caveat is that noHistory is not a guarantee of no history ever, just that history will be dropped from indexes. so you may still see some history between the last indexing job and now

also I don’t know if history disappears from transaction logs

I see in the docs that the indexes are stored in S3. Would it be correct to say that :db/noHistory = :db/noS3? Or just that the datom will eventually not exist in S3? > The effect of :db/noHistory happens in the background Maybe that’s what this means. The datom is eventually scrubbed from S3 in the background..?

> also I don’t know if history disappears from transaction logs Looking in the docs again, this would mean that it’s still stored somewhere at the end of the day, yeah? DDB in this case. And these datoms would still show up in d/tx-range.

I don’t know the ins-and-outs of cloud

for on-prem, tx log data is written to storage and kept in peer+transactor memory until the next index kicks in. Reads transparently merge the last index time with the in-memory index derived from the tx log; but when the in-memory index is flushed to storage, the history of no-history attributes is not written. I don’t know if the transactor also takes the additional step of rewriting the tx-log to remove attribute history, but it seems unlikely to me. For cloud, I don’t know the precise mechanics of where that in-memory log goes or what precisely happens during indexing

anyway, this is easy to test. If it matters to you it’s probably better than listening to me speculate

actually only on-prem is easy to test. on cloud there’s no d/request-index, so you will have to induce it some other way (probably via lots of writes).

it will stay in history logs

Thanks for the info guys 🙏

…you mean on-prem?

I think he meant a version where all you have to do is get credentials, download the client and you're good to go. This is what I thought cloud was going to be initially. Right now, you still have a lot of moving pieces with all the AWS stuff you have to setup yourself.

yeah. Exactly.

I don't feel confident at the moment that i can maintain AWS setup on my own in a small team

maybe someday if get up to speed with AWS properly

Possibly on-prem has a lower support burden? It is less embedded into aws

run a transactor, run a peer, use dynamo for storage

ah.. maybe

but i would really prefer not running my own database