This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # bangalore-clj (6)
- # beginners (110)
- # boot (49)
- # cider (13)
- # cljs-dev (35)
- # cljsrn (5)
- # clojure (145)
- # clojure-conj (3)
- # clojure-dev (60)
- # clojure-italy (2)
- # clojure-nl (3)
- # clojure-russia (3)
- # clojure-serbia (1)
- # clojure-spec (116)
- # clojure-uk (58)
- # clojurescript (235)
- # cursive (14)
- # datascript (7)
- # datomic (31)
- # dirac (144)
- # emacs (1)
- # events (1)
- # hoplon (12)
- # leiningen (11)
- # luminus (60)
- # lumo (19)
- # off-topic (18)
- # om (74)
- # onyx (5)
- # pedestal (13)
- # precept (3)
- # re-frame (3)
- # reagent (15)
- # remote-jobs (7)
- # ring-swagger (25)
- # rum (1)
- # untangled (53)
- # vim (3)
How are you all structuring your code for database functions? I assume: have small interfaces in datomic and put the rest of the code on the classpath of the transactor?
@stijn i really dislike that approach because it means regular transactor downtime (every time you have code to deploy)
@uwo Note that those peers are still able to write to the Datomic instance (i.e. submit transactions), as that work is handled through peer->transactor->storage
it probably isn’t a terrible idea just in the sense that your peer user creds are less open
Ah I misunderstood what you were after @uwo. With respect to storage, all peers are read-only. But there's no way to turn off their ability to submit txs to the transactor
incidentally, I believe ‘read only peer’ would be appropriate as a feature request in our portal - I’d suggest you add it there if it’s not already in there
It looks to me like
com.datomic/datomic-pro "0.9.5561" depends on
org.apache.httpcomponents/httpclient "4.5.2" which depends on
com.datomic/datomic-pro "0.9.5561" also depends on
commons-codec "1.5" directly, overriding httpcomponents' dependency and forcing the older
1.5 version of commons-codec.
Is this right? Is it good? What is the reasoning? If the code in datomic-pro is compatible with commons-codec 1.9, then I think removing the direct dependency on 1.5 is a good idea.
Are there any performance improvements to be gained by using enums for attributes that are in some sense bounded? For example, I have a lot of data that needs to be retrieved by day (in the bi-temporal sense, not the t). Indexing millions of entities by day seems wasteful if the universal set of days is bounded to a few years, e.g. :as-of/+20170622 is not too cumbersome to use. Basically, will I get the same query performance swapping out indexes for enums?
@harold: I've just added a
[commons-codec "1.10"] top-level dependency to my project.clj in order to pin the dependency, personally (I'm extra-paranoid about class-loading conflicts)
@timgilbert - that sounds dicey too, if httpcomponents depends on 1.9 specifics the change you suggest could break it (same for datomic and commons-codec 1.5, and datomic's explicit direct dependency suggests to me that it does depend on 1.5 specifics).
I agree, but to me that diceyness is a lot more palatable than the diceyness of "include two copies of these classes in the classpath and let the fates decide which version the JVM will load on each invocation"
FWIW, from the changelog of commons-codec it looks like largely just bugfixes in more recent versions
lein or mvn will pick one, not include both (but that one might not be the one you want)
Oh right. Well, build-time uncertainty is better than run-time uncertainty, but not by that much
@alexmiller - any thoughts on this conflict? Is there a better place to report/post it?
@alexmiller - Oh, didn't think of that. I don't interact much with the datomic licensing stuff we do. Thank you.