Clojurians Log v2

Please forgive me if I'm misunderstanding, but this doesn't seem quite right. It's perfectly possible to use persistent storage from clojure without explicitly using atoms.

We could talk about the design a little bit if you like @franquito .

Hi! Thanks, if It's ok with you I'll ping you once I have an idea about how all the tools work together (I'd like to check how hitchhicker trees, konserve and datahike play together). Although right now I'm curious to know about how datahike-server plans to solve the concurrency problems that datomic transaction functions solve.

probably but are you talking normal coding convention or technicalities

datahike.db/explode/iter/fn                  db.cljc: 1198
                         datahike.db/validate-attr                  db.cljc:  984
clojure.lang.ExceptionInfo: Bad entity attribute :db/retract at #:db{:id 149, :retract [:message/content "f78a3ec0-6c97"]}, not defined in current schema
    attribute: :db/retract
      context: #:db{:id 149, :retract [:message/content "f78a3ec0-6c97"]}
        error: :transact/schema

Ah, you can retract a lot of tuples like :db/retract [pairs-of-tuples-here] i think... testing it out now 🙂

(defn commence-remove-upvote 
  "removes an upvote with retract transaction" 
    [messageid authorid] 
			 (d/transact conn [ {:db/retract [:message/content   messageid]
								         :message/authorid authorid
									     :message/kind      "upvote"}]))

;_; no dice

clojure.lang.ExceptionInfo: Bad entity attribute :db/retract at #:db{:id 154, :retract [:message/content "6b45b69c-11d5" :message/authorid "<mailto:jack@satisologie.com|jack@satisologie.com>" :message/kind "upvote"]}, not defined in current schema

almost there.. {} was not right, [] was the answer... hopefully a unique dbRef will be all i need now

I would go so far as to say that what you're suggesting isn't even necessarily a "normal coding convention" in Clojure. Just as an example, Datomic databases don't use atoms in any part of the interface. It's cool/interesting that DataScript used simple atoms for state but that doesn't make this a typical pattern. More generally though, Clojurists read and write data files all the time, and there's almost never a reason to use atoms in the process of that (unless the point of the process is to stick in an atom for other reasons).

Moreover, you don't want non-idempotent (such as file writing) operations to take place in functions passed to swap!, since they can get executed more than once if multiple calls to swap! are happening concurrently for a given atom.

Again, I may have simply misunderstood what you were trying to say here, so please let me know if I misunderstood your intentions.

Yes, or, if you do care more about storage cost than throughput, the dynamodb + s3 combination in https://github.com/csm/konserve-ddb-s3.

We have implemented most of the features that have been built into this codebase in the underlying libraries now, so to get production ready a few things need to be factored. But I think it should still work as it is. I have never used it though.