or like https://github.com/metasoarous/datsync > • Every entity gets a :datsync.remote.db/id mapping to the Datomic id

more notes for when i'm more awake tomorrow https://clojurians-log.clojureverse.org/datascript/2021-09-14

https://stackoverflow.com/questions/68381743/datomic-ids-in-datascript

this datasync function might be useful (dat.sync.client/datomic-tx conn tx) if it wasn't depreciated...

Hi there, I'm doing something similar, so far I've had success saving the server’s id in the diatomic client. I basically have a pair of functions that transmit datoms (or should the plural be data? :thinking_face:) between server and client that manage sorting out the translation for the ids.

It's probably similar to datasync. Client side I have a unique attribute called :server/id. When the client sends data to the server it replaces the datascript id with the value of that attribute, otherwise it sends the diatomic id as a string. Then the server sends back the tempids map from the transaction result, and the client uses that to set the :server/id attribute. When the server sends data to the client it renames the :db/id field to :server/id

@U03NXD9TGBD what do you mean "otherwise it sends the diatomic id as a string" Shouldn't it be find to replace the shorter client db/id's with the :server/id as an integer as long as you don't do an operation on it which only works with the shorter version (see datascript issue for details that i don't fully understand myself).

Though, wouldn't a better solution be to just have a uuid attached to each datom and sync on that? I think datomic's build in db/id's aren't meant to be universal unique, more for indexing purposes.

Here is my plan. In order to sync datoms they will use the db.unique/value db/uuid. The only additional cleanup is that ill have to have each peer ignore the db/id attribute, possible just by stripping it or renaming it before being sent.

probably removing it is better, i feel like renaming it would just lead to confusion....

What does this comment mean from tonsky mean.. > It seems that long ids are no longer supported on JVM since 0.18.0. I also added a validation that throws on both JVM and JS if value is out of range. why does the jvm care about ids? ids of what?

Sorry, I apparently left out some context. I let datascript manage the ids as usual, and I attach the datomic id under :server/id . So when I want to send data to the server there are two cases. Where the client entity already has a :server/id from datomic, and the other when a client entity has been created on the client, in which case there won't be a :server/id. In both cases the datascript db/id is the normal datascript id. Here is my client->server transformation, it's purpose is to transform a datascript :db/id into the matching datomic :db/id.

(defn ref->datomic [db ref]
  (or (-> (and ref (d/pull db '[:server/id] ref))
          :server/id)
      (str ref)))

(defn save-sever-ids [[client-id server-id]]
  [:db/add (edn/read-string client-id) :server/id server-id])

(defn sync-pending-txs! []
  (go (let [edn-params (pending-txs->datomic)
            response (<! (http/post "/sync"
                                    {:with-credentials? true
                                     :edn-params edn-params}))]
        (->> (get-in response [:body :tempids]) ; Get the newly created entity ids
             (map save-sever-ids) ; Convert them into transaction commands
             (into [])
             (d/transact! @sync-conn))
        (reset! pending-txs []))))

> In order to sync datoms they will use the db.unique/value db/uuid. The only additional cleanup is that ill have to have each peer ignore the db/id attribute, possible just by stripping it or renaming it before being sent. This is a good plan, unfortunately because of other reasons specific to my app, There are some entities that I can't attach a UUID to, so I need to go through this translation. For details, I'm basically making a markdown editor so I'm tracking dom nodes. I attach a unique UUID to each html tag via attributes (ie <p dom-id="<UUID>">). However text nodes don't have attributes, so I can't treat them the same and I have to go fishing into the db to figure out how to sync them.

thanks a lot @U03NXD9TGBD. I think we might end up doing the server/id translation for a bit to until we have time to think through using the uuid. It's nice because it just adds some computational overhead and doesn't effect any existing entities in the db.

So far it's worked out for me, but there could be some gotchyas that I haven't uncovered… If you hit any edge cases I'd be interested to hear about them!

It would seem like the client or the server could hold the mapping, why prefer the client?

I expect there to be multiple clients all with different ids figured it's easier to track one server id rather than multiple client ids.