lambdaconnect-sync.hooks — io.spinney/lambdaconnect-sync 1.0.37

concat-hooks-push-transactions clj/s

(concat-hooks-push-transactions hooks-transaction push-transaction)

get-colliding-ids-attrs clj/s

(get-colliding-ids-attrs transaction1 transaction2)

get-datomic-relationships clj/s

(get-datomic-relationships config snapshot)

get-datomic-relationships-from-model clj/s

(get-datomic-relationships-from-model entities-by-name)

get-id-to-correct-id clj/s

(get-id-to-correct-id config snapshot-before snapshot ids)

get-ids-from-entry clj/s

(get-ids-from-entry datomic-relationships entry)

get-ids-from-transaction clj/s

(get-ids-from-transaction datomic-relationships transaction)

send-specific-hooks! clj/s

(send-specific-hooks! config
                      before-snapshot
                      snapshot
                      interesting-objects
                      entities-by-name
                      user
                      hook-fun)

(send-specific-hooks! config
                      before-snapshot
                      snapshot
                      interesting-objects
                      entities-by-name
                      user
                      hook-fun
                      common-state)

(send-specific-hooks! config
                      before-snapshot
                      snapshot
                      interesting-objects
                      entities-by-name
                      user
                      hook-fun
                      common-state
                      previous-results
                      finaliser-fun)

This function takes a map of {"entity-name" {uuid1 obj1 uuid2 obj2 uuid3 obj3]}

It uses the snapshot to re-fetch all the objects using just their uuids (the obj1 obj2 obj3 etc. are ignored). Snapshot would most likely be a speculated db (after applying push transaction).

It then calls the hook-fun for each object, expecting it to return transaction pairs (message-queue and main db). This way the creation/update of push objects can have some db-related side effects.

The hook functions are instructed of the current state of the speculated db (snapshot), state of the db before speculation (before-snapshot), object to consider, user that has triggered the push and finally some shared state that can be used to track advanced changes between calls (necessarily an atom!).

Finally, if the finaliser function is provided, it is called with final transactions and shared state and provides its own transaction/mq-transaction pair state.

At the very end, a transaction or a map {:transaction mq-transaction} is being returned.

update-colliding-entry clj/s

(update-colliding-entry colliding-ids-attrs entry)

update-ids-in-entry clj/s

(update-ids-in-entry datomic-relationships id-to-correct-id entry)

update-ids-in-transaction clj/s

(update-ids-in-transaction config
                           datomic-relationships
                           transaction
                           snapshot-before
                           snapshot)