Hey @U0GC1C09L, can you import up to the bad transaction, transact all non-bad attrs of the bad transaction, then import again starting at t+1 of the bad transaction?

hey Joe, thanks for the response. i suppose i could, but this is part of a larger workflow to backup and "restore" Cloud dbs. if possible i'd like to avoid coding in edge cases for specific databases, or catching exceptions and iterating the import process for "bad" datoms that clearly do exist in the history. i will if we need to, but this feels like an issue with dev-local and a clash between its constraints and the constraints of datomic cloud

i'm picturing some interesting cases for tracking all of the datoms in the skipped transaction, and then deciding how to handle future transactions against them as we replay the transaction log. for example: only replay retractions of skipped datoms when there has been an addition between a skipped transaction and the transaction being replayed. oof.

Where do you see that? Rules are scoped to a single datasource and cannot realias, but you can invoke them with a different datasource ($ds rulename …) and inside the rule $ is available

I suppose the target hosts security group allows connections on any port from the VPC?

No

generally t and txes are interchangeable in any time-filtering functions

how do I point to an older point in time? should I use t or tx?!

You need a “real” tx if you want to look at the TX entity itself

but for things like as-of, tx-range, sync, etc, they accept T or TX

no

transactions are entities

That’s how this technique is possible: https://docs.datomic.com/on-prem/best-practices.html#add-facts-about-transaction-entity

Can I use this?

(defn t->tx
  [t]
  (+ t 13194139533312))
(defn tx->t
  [tx]
  (- tx 13194139533312))

I'm no expert, but I don't think these things have that relationship in cloud, so no

I tried to do a :thing/as-t that points to a point in the pass But I can't use this because I need to create it for older entities and I don't have the t anymore So I changed my approach: :thing/as-tx Now is easy to create thing entities for older entities in DB, but it's hard to create for newer ones, once for newer ones I get the t from the db and I can't save the t value

I can create a :thing/as-of where sometimes it is a t and other times it is a tx This is a good idea?

Can we step back? what problem are you solving?

Are you accidentally falling into this trap? https://vvvvalvalval.github.io/posts/2017-07-08-Datomic-this-is-not-the-history-youre-looking-for.html

I need to create a entity that references another entity in a exact point in time.

Putting the modeling question aside, how do you decide on what moment in time?

something like: this report entity is generated from this entity at this db.

how do you arrive at “this db”?

At this moment, my code is:

(defn do-report
   [db id]
   .... {:tx-data [... {:report/db (:t db)}]})

(You never run that fn with a filtered (e.g. as-of) db?)

I agree not having t->tx is annoying, and I’m concerned by alex’s comment, it’s a pretty fundamental relationship and difficult to imagine cloud being different

It’s quite easy to write yourself (just some bit-masking) but alex is giving me pause

however, you may be better off querying for a specific tx entity to use, then using that with an as-of; or you could use tx-range to find the transaction corresponding to the basis T and inspect its data for the :db/txInstant assertion

(def ^:const ^long MASK-42
  2r000000000000000000000111111111111111111111111111111111111111111)
(def ^:const ^long TX-PART-BITS
  2r000000000000000000011000000000000000000000000000000000000000000)

(defn tx->t ^long [^long t]
  (bit-and MASK-42 t))

(defn t->tx ^long [^long t]
  (bit-or TX-PART-BITS (bit-and MASK-42 t)))

This definitely works for on-prem

The “tx-part-bits” is just the number 3 (= the entity-id of the “tx” partition) shifted over 42 bits

d/entid-at on on-prem lets you compute entity-ids for arbitrary partitions